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FOREWORD 


This  report  entitled  "TRADOC  RAM  Data  Evaluation 
System  (TRADES)"  is  an  American  Power  Jet  Company  (APJ) 
study  effort  issued  in  five  parts: 

Part  I:  Executive  Summary  and  Brief 

Part  II:  Study  Work  Plan 

Part  III:  System  Requirements 

Description 

Part  IV:  Alternative  Concepts 

of  Operation 

Part  V:  System  Technical  Paper  (This  Report) 

This  Part  of  the  final  report  documents  the  data 
system  concept  which  includes  the  overall  concept  of 
operation,  internal  and  external  procedures,  hardware 
and  software  requirements,  and  personnel  implications. 
The  report  also  recommends  that  TRADES  capitalize  on 
the  currently  available  and  programmed  hardware  within 
TRADOC,  which  significantly  reduces  implementation  costs 
and  time. 

A  draft  version  was  submitted  as  APJ  892-4,  and 
presented  to  the  SAG.  Their  comments  and  recommenda¬ 
tions  are  incorporated  herein  and  are  gratefully  acknowl 
edged. 
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CHAPTER  I 


INTRODUCTION 


SYSTEM  TITLE 

This  study  is  entitled  the  "TRADOC  RAM  Data  Evalua¬ 
tion  System  (TRADES)  (ACN  51235):  Phase  II." 
References  made  to  the  acronym  "TRADES"  throughout 
this  report  will  refer  to  the  TRADOC  RAM  Data 
Evaluation  System  and  not  to  the  present  study. 

SUBJECT  OF  THIS  REPORT 

This  specific  report  is  called  the  "System  Technical 
Paper  (STP),"  and  accomplishes  the  fourth  task  in 
the  TRADES  concept  development  study  being  performed 
by  the  American  Power  Jet  Company  (APJ)  for  the 
U.S.  Army  Logistics  Center.  The  three  previous 
reports  respectively  covered  the  topics  of  the 
Study  Wcrk  Plan  (SffP),  the  System  Requirements 
Description  (SRD),  and  the  Alternative  Concepts  of 
Operation  (ACO).  This  STP  report  will  be  followed 
by  the  Final  Study  Report  (FSR)  which  will  include 
all  of  the  previous  reports.  A  more  detailed 
description  of  each  task  is  provided  in  the  SWP. 

BACKGROUND 

The  need  for  TRADES  has  evolved  due  to  the  ever- 
increasing  complexity  of  weapons  systems  and  the 
need  for  the  combat  developer  to  establish  standards 
to  ensure  that  these  expensive  systems  will  work 
when  fielded.  Realistic  RAM  parameters  and  thresh¬ 
olds  must  be  prescribed  which  are  based  on  user  needs 
for  system  effectiveness  and  logistics  support ability 
in  view  of  system  design,  state-of-the-art  technology, 
and  performance  achieved  by  fielded  equipment.  Great 
care  must  be  taken  in  establishing  RAM  requirements 
because  of  their  significant  effect  on  development 
and  operating  and  support  costs,  and  on  equipment 
readiness. 

TRADES  is  envisioned  as  an  information  system 
which  would  provide  the  TRADOC  combat  developer 
with  responsive  near  real-time  automated  reliability, 
availability,  and  maintainability  (RAM)  information. 
This  would  include  engineering,  test,  and  field 
data,  and  is  designed  to  provide  the  capability  to 
support  requirements  determination  and  test  analyses 
for  materiel  under  development.  A  complete  summary 
of  TRADES  and  its  background  is  included  in  the 
SRD. 
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PHASES 


The  TRADES  study  effort  has  three  phases:  Phase  I 
established  the  requirement  for  a  TRADES  system; 

Phase  II  (the  current  phase)  in  essence  portrays 
the  concept  for  an  operational  TRADES;  Phase  III, 
if  approved,  will  address  the  implementation  of 
TRADES  as  an  operating  system  for  the  TRADOC 
community.  It  should  also  be  noted  that  although 
the  system  is  being  developed  for  TRADOC,  other 
potential  users  in  the  Army  have  been  identified. 

PURPOSE  OF  THE  STP 

The  purpose  of  the  STP  is  to  develop  and  document 
a  data  system  for  the  alternative  concept  of 
operation  using  the  Planning  Factors  Data  Base 
(PFDB).  The  PFDB  ACO  was  selected  from  among  five 
alternative  courses  of  action,  and  is  used  as  the 
framework  on  which  to  base  the  TRADES  concept. 

Whereas  the  ACO  report  provided  sufficient  information 
for  comparative  judgments,  the  STP  focuses  on  the 
selected  system  and  expands  on  its  operation, 
characteristics,  features,  required  resources,  and 
the  next  steps  for  implementation  of  TRADES.  This 
paper  will  include  the  overall  concept  of  operation, 
internal  and  external  operating  characteristics, 
hardware  and  software  requirements,  and  personnel 
implications  as  prescribed  by  the  SOW  and  further 
guidance  from  the  SAG. 

SCOPE  AND  SUMMARY  OF  CHAPTERS 

The  PFDB  ACO  was  conceptually  developed  and  briefed 
to  the  SAG  on  24-25  August  1981.  This  report, 
therefore,  describes  in  greater  detail  the  relevant 
features  and  resources  required  for  the  TRADES 
system. 

Chapter  I  (Introduction)  provides  the  background 
to  TRADES  and  to  this  report. 

Chapter  II  (Methodology)  describes  the  methodology 
used  in  the  preparation  of  the  STP.  It  includes  a 
description  of  the  methods  used  to  access  data, 
process  and  analyze  information,  and  to  record  the 
results  of  these  investigations.  References, 
agencies  and  individuals  consulted  are  also  listed. 

Chapter  III  (Concept  of  Operation)  provides  an 
overview  of  the  TRADES  concept  of  operation  using 
the  PFDB  alternative.  The  concept  also  treats  the 


specific  objectives  of  the  system  and  describes 
the  type  and  volume  of  the  data  base  contents. 

Formats  of  reports,  sources  of  information,  storage 
requirements,  and  interfaces  between  users,  data 
sources,  and  automated  systems  are  detailed.  It 
is  noted  tnat  the  SOW  originally  entitled  this 
chapter  as  the  Concept  of  Automation.  However, 
the  SAG  provided  the  guidance  that  the  broader 
concept  of  operation  should  be  included  in  this 
chapter  with  the  details  of  automation  covered  in 
subsequent  chapters. 

Chapter  IV  (Internal  Operating  Characteristics) 
describes  the  appropriate  techniques  for  data 
retrieval,  processing,  and  dissemination  in  narrative 
form.  Flow  charts  are  provided  which  form  a  basis 
for  functional  understanding  of  the  system,  and  are 
sufficiently  detailed  to  permit  definition  and  design. 
This  chapter  also  describes  procedures  for  acquiring, 
verifying,  and  storing  data.  (Definition,  design, 
and  programming  activities  for  TRADES  will  occur 
in  the  later  life  cycle  stages  of  TRADES). 

Chapter  V  (External  Operating  Procedures)  provides 
a  detailed  description  of  the  procedures  by  which 
the  user  can  obtain  the  required  products  from 
TRADES.  It  provides  an  estimate  of  the  frequency 
and  volume  of  data  requirements  for  each  prospective 
user.  This  chapter  also  discusses  the  TRADES 
organization  required  to  acquire  data,  maintain 
the  system,  and  service  the  users. 

Chapter  VI  (Hardware  Requirements)  reviews  the 
hardware  characteristics  of  the  PFDB  alternative 
and  details  the  requirements  and  modifications 
necessary  to  incorporate  TRADES.  Attention  is 
given  to  peripheral  equipment,  remote  terminals, 
access/storage  devices,  output  equipment,  and 
communications  equipment  needs. 

Chapter  VII  (Software  Requirements)  addresses  the 
Data  Base  Management  System  (DBMS)  and  describes 
each  of  the  four  modules  which  perform  the  TRADES 
functions.  Consideration  is  given  to  the  expected 
computer  capabilities,  requirements  for  TRADES, 
and  realistic  expectations  for  state-of-the-art 
improvement  in  software  development. 
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Chapter  VIII  (Personnel  Requirements)  provides  a 
functional  identification  of  the  personnel  required 
to  operate  and  maintain  the  TRADES  system.  This 
includes  a  description  of  actions  at  user  level  as 
well  as  for  data  sources,  functional  proponents, 
and  ADP  proponent . 

Chapter  IX  (Conclusions)  provides  a  summary  of  the 
study,  stressing  TRADES  implications  and  subject 
issues,  hardware,  software,  and  personnel  require¬ 
ments.  Benefits  and  problem  areas  are  emphasized 
and  the  potential  increased  productivity  of  the 
user  is  weighed  against  technical  risks  involved 
in  the  development  of  TRADES. 

Chapter  X  (Recommendations)  specifies  further 
actions  needed  to  implement  TRADES.  These  include 
comment  on  inoperative  data  accumulations  and 
prototyping  activities  to  support  the  parallel 
development  of  TRADES  under  the  provisions  of 
AR  18-1. 

Certain  flow  diagrams  and  descriptions  previously 
presented  in  the  aforementioned  reports  are  used 
directly  in  this  report  to  maintain  continuity  and 
avoid  the  need  for  excessive  cross  referencing. 
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CHAPTER  II 


METHODOLOGY 


PURPOSE 


This  chapter  contains  methodological  notes  and 
explains  the  procedures  used  for  the  preparation 
of  the  STP.  This  portion  of  the  task  of  TRADES 
concept  development  is  best  characterized  as  the 
emerging  concept  of  TRADES. 

As  originally  conceived,  the  STP  was  to  be  a 
recapitulation  of  the  ACO  selected  for  the  develop¬ 
ment  of  TRADES.  The  process  identifies  the  needs 
of  the  user  and  sources  of  information  from  the 
SRD,  and  applies  them  to  the  ACO  selected  for 
TRADES.  The  actual  developmental  process  of 
TRADES  has  proven  to  be  a  dynamic  one,  with  processes 
and  procedures  of  the  TRADES  concept  interactively 
modified  during  each  task  and  SAG  review  session. 


PROCESS 


The  evaluation  process  entails  observation  and 
analysis  of  existing  procedures,  and  the  conversion 
of  those  processes  to  a  more  efficient  compatible 
method  using  automation. 

TRADES,  however,  initiates  a  new  process  and  involves 
basic  investigation  of  several  systems  not  yet 
fully  in  being  or  fully  standardized.  Therefore, 
the  analyst  is  in  fact  planning  a  concept  with 
the  requirement  that  all  systems  with  which 
TRADES  will  interface  will  in  fact  be  able  to 
provide  the  desired  information  and  implies  the 
development  of  essential  interfaces. 

FUNCTIONAL  DESCRIPTION 

Understanding  this  point  has  mandated  the  review 
of  the  concept  of  operation  of  TRADES  at  each 
major  step;  in  the  development  process,  it  is 
continuously  updated  as  the  finer  grain  of  TRADES 
is  refined  in  each  development  phase.  As  will  be 
noted  in  the  Recommendation  Chapter,  the  development 
of  a  Functional  Description  (FD),  as  required  by 
DoD  Standard  7935.1-5,  Automated  Data  Systems 
Documentation  Standards,  should  be  initiated  as 
early  as  possible.  The  FD  is  defined  in  the  DoD 
Standard  as  follows: 
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"An  FD  (Functional  Description)  is  normally  prepared 
for  any  system  requiring  a  basis  for  mutual  under¬ 
standing  between  the  Development  Group  and  the 
User  Group  of  a  proposed  ADS.  It  reflects  the 
definition  of  the  system  requirements  and  provides 
the  ultimate  users  with  a  clear  statement  of  the 
operational  capability  to  be  developed.!  If  the 
scope  of  the  FD  is  changed  at  any  point,  the  FD 
should  be  updated  and  receive  user  concurrence." 

"The  FD  is  a  tool  for  use  by  both  computer  and 
noncomputer  personnel  and  should  be  written  as 
much  as  possible  in  noncomputer-oriented  language, 
since  many  elements  of  the  document  will  be  subject 
to  review  by  staff  personnel  who  do  not  necessarily 
have  a  computer  background." 

The  FD  then  is  essentially  a  living  document  that 
reflects  the  concept  of  operations  and  forms  a 
basis  of  understanding  between  the  user  and  the 
personnel  designing  the  TRADES  system. 


ANALYSIS 

Source  Information 


One  of  the  conclusions  of  the  SRD  was  the  plethora 
of  source  information.  In  fact,  this  varied 
complexity  of  data  is  precisely  a  major  reason  for 
the  need  for  TRADES,  which  facilitates  the  ability 
of  TRADOC  RAM  engineers  to  obtain  RAM  performance 
data  for  the  combat  development  process. 

To  form  a  baseline  for  development  of  TRADES  for 
full  implementation  in  1985,  it  was  necessary  to 
focus  on  the  major  source  systems  which  are  planned 
for  operations  in  that  period  of  time  (Table  2-1). 
The  TRADES  system  will  be  built  around  these 
primary  systems  with  the  other  sources  of  data 
interfacing  on  an  "as  required"  basis. 


TABLE  2-1.  PRINCIPAL  LIFE  CYCLE  PHASE  DATA  SOURCES 


DEMONSTRATION 

AND 

VALIDATION 

FULL  SCALE 

ENGINEERING 

DEVELOPMENT 

PRODUCTION 

AND 

DEPLOYMENT 

Logistics  Support  Analysis 

LSAR 

Standard  Army  Maintenance 

Report  (LSAR) 

System  (SAMS) 

Common  RAM  System  (COMRAM) 

COMR.AM 

Sample  Data  Collection 

Common  Test  Data  Collection- 
System  (CTDCS) 

CTDCS 

(SDC) 

TRADOC  System* 

Defense  Technical  Info. 
System  (DTIC) 

TRADOC  System* 

DTIC 

*  Hard  copy  and  local  automated  data  developed  by  TRADOC  test  boards 


User  Orientation 

One  of  the  principal  lessons  learned  from  the  SAG 
guidance  is  the  need  for  TRADES  to  be  focused  on 
the  user's  needs;  i.e.,  the  TRADOC  schools  and 
centers.  To  determine  the  marginal  cost  difference 
among  the  ACOs,  a  constant  requirement  was  assumed 
at  the  schools  and  TRADOC  System  Managers  (TSMs) 
and  therefore  did  not  feature  the  TRADES  total 
system  costs.  The  STP  places  the  focus  on  the 
TRADES  user  resource  requirements  derived  from 
input  by  the  SAG  members  and  reflects  the  entire 
system  resource  requirements. 

Also,  the  question  of  distributed  versus  centralized 
processing  was  further  analyzed.  It  should  be 
reemphasized  that  the  central  features  of  TRADES 
places  the  updating  responsibilities  on  one  organi¬ 
zation,  with  control  of  selected  input  by  proponents 
This  concept  permits  users  to  utilize  computers 
available  at  their  home  station  (rather  than  just 
basic  terminals)  to  process  RAM  information  as 
desired  by  that  activity.  The  "sunk  cost"  feature 
of  using  the  centralized  in-being  computers  is  an 
essential  element  of  the  TRADES  concept. 


Hardware  Assumptions 


In  order  to  ensure  a  high  level  of  confidence  in 
the  envisioned  min_-computer  capabilities  and 
requirements  estimates,  actual  equipment  assumptions 
were  made.  These  are  detailed  at  appropriate 
places  in  the  STP.  These  representations  are  made 
to  facilitate  comparisons  and  analysis,  and  are 
not  to  be  construed  as  a  statement  of  need  for  any 
particular  make  and  model  of  automatic  data 
processing  (ADP)  equipment.  The  computers  currently 
located  at  the  (DPFO)  in  Fort  Leavenworth,  Kansas, 
and  Operations  Analysis  Directorate  (OAD)  at  Fort 
Lee,  Virginia,  are  assumed  for  the  STP  purposes 
only  and  will  not  restrict  changes  which  may  be 
made  by  the  Army  in  the  follow-on  phases.  System 
design  at  this  stage  is  not  dependent  on  any 
particular  type  of  computer  and  is  constrained  only 
by  size  and  capability  limitations. 

The  primary  advantages  of  the  centralized  system 
must  be  considered  and  evaluated  in  contrast  to  a 
totally  decentralized  system.  While  the  TRADES 
system  recognizes  and  acknowledges  micro-computer 
capabilities  at  user  level,  this  is  recommended  as 
an  enhancement  and  follow-on  after  the  initial  use 
of  currently  existing  and  available  equipment. 

The  most  important  aspect  retained,  however,  is 
centralized  programming  of  the  overall  TRADES 
system  to  achieve  a  uniformity  of  available  data 
and  procedures  for  consistent  application  and 
comprehension  of  results. 

The  primary  advantages  of  a  totally  decentralized 
TRADES  are  the  avoidance  of  any  potential  queueing 
problem  and  the  ability  to  operate  on  an  individual 
initiative  basis.  The  disadvantages  include 
potential  unique  development  of  information,  lack 
of  uniformity  and  discipline,  and  a  de  facto  need 
for  personnel  to  operate  and  manage  the  system 
with  no  economy  of  scale. 

Our  conclusion  is  that  the  partially  distributed 
concept  of  TRADES  permits  local  expansion  where 
the  talents  and  requirements  make  this  a  logical 
development.  However,  the  bulk  of  the  TRADES 
users  are  not  anticipated  to  have  the  requirement 
for  this  capability,  which  will  be  available  in 
the  centralized  TRADES  system. 


*  ■ 
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TRADES  Life  Cycle  Overview 


Although  TRADES  will  not  likely  require  DA  level 
approval  (devexopmental  costs  are  anticipated  to 
be  less  then  $3M),  AR  18-1  functions  as  an  umbrella 
over  all  Army  automation  management.  Therefore, 
the  provisions  of  this  regulation  must  be  recognized, 
and  recommendations  for  TRADES  are  within  the 
parameters  of  this  regulation. 

In  accordance  with  AR  18-1  and  TB  18-100,  TRADES 
life  cycle  is  comprised  of  five  major  phases  in 
relationship  to  the  management  milestones.  (See 
Figure  2-1). 

TRADES  is  being  developed  at  a  time  when  Automated 
Data  Systems  (ADS)  developmental  procedures  are 
changing.  Because  of  this,  TRADES  concept  actions 
do  not  parallel  those  actions  now  required  for  the 
development  cycle  of  ADS.  However,  current  regulations 
are  flexible  enough  to  permit  modifications  of 
standards  to  the  size  and  requirements  of  whatever 
system  is  being  developed.  It  seems  that  it  would 
be  good  judgment  to  re-align  the  TRADES  development 
cycle  on  the  milestone  and  phases  currently  being 
used.  Para.  1-8,  b,  (7)  (d)  of  T3  18-100,  Army 
Automation,  15  Dec  80,  requires  initial  functional 
requirements  using  documentation  in  TB  18-111.  In 
addressing  documentation  requirements,  Para.  2-5  a 
of  TB  18-111,  Army  Automation  Technical  Documentation, 
Jan  1979,  states  that  DOD  Standard  7935.1-5  is  to 
be  followed  using  the  Functional  Description.  It 
is  imperative  that  the  functional  description  be 
initiated,  as  discussed  in  Chapter  II  of  the  STP. 

Other  Actions 


Actions  should  be  taken  to  bring  the  development 
of  TRADES  into  line  with  the  requirements  of  these 
regulations.  These  actions  are  detailed  in  Chapter 
X  (Recommendations). 


Phase  II 


As  shown  in  Figure  2-1,  Phase  I  (Feasibility  Study) 
has  been  completed.  TRADES  is  now  in  concept 
development  with  the  present  effort  developing  the 
final  concept  (corresponding  to  Milestone  I),  with 
the  description  presented  in  the  STP. 
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Figure  2-1.  TRADES  Life  Cycle  Overview 


Phase  III 


"  s' 


The  next  phase  of  the  work  program  will  concern 
the  definition  and  design  of  the  accepted  TRADES 
system  prior  to  Milestone  II.  A  major  initial 
effort  in  Phase  III  will  be  the  organization  of 
the  data  base,  and  development  of  the  appropriate 
taxonomy  to  facilitate  RAM  data  searches  and 

provide  for  efficient  and  effective  categorization 
of  the  data  base.  The  organization  of  the  data 
base  and  development  of  the  taxonomy  will  provide 
major  inputs  to  the  actual  design  of  the  system  to 
complete  Phase  III. 


An  inherent  characteristic  required  of  TRADES  is 
that  it  be  capable  of  being  prototyped  and  permit 
its  evolution  in  the  direction  of  maximum  customer 
service.  This  infers  tnat  RAM  data  is  not  a  "once 
and  for  all"  requirement  set  by  current  RAM  require¬ 
ments  documents  or  users,  or  indeed  by  the  present 
users'  view  of  what  they  need.  These,  to  the  con¬ 
trary,  are  only  starting  points. 

This  prototyping  in  Phase  III  could  address  a  single 
data  source  as  an  initiation  point  for  debugging  the 
system,  and  then  progress  into  full-scale  implemen¬ 
tation  of  total  RAM  data  sources  in  Phase  IV, 


Phase  IV 

Phase  IV  consists  of  the  TRADES  system  development, 
with  the  major  effort  in  programming  and  debugging 
the  system  prior  to  Milestone  III. 


Training 


Once  TRADES  is  operational,  it  must  respond  to 
changes  and  needs  of  the  user  community,  as  well 
as  to  increasing  availability  of  RAM  data  at  any 
point  in  its  life  cycle.  The  team  must  determine 
weak  spots  in  the  source  data  and  use  the  TRADES 
system  to  secure  action  in  areas  of  maximum  return. 
This  implies  a  highly  competent  TRADES  management 
team,  comprised  of  human  beings  using  the  computer 
as  only  one  of  their  tools  in  meeting  their  missions 
and  functions. 
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CHARACTERIZATION  OF  TRADES 


It  must  be  emphasized  that,  TRADES  is  not  primarily 
a  data  base,  but  a  system  to  facilitate  the  extraction 
and  manipulation  of  data  from  otner  data  systems. 

Inf  rmation  deriv<  d  from  calculations  as  well  as 
reports,  once  extracted,  are  included  within 
TRADES  to  facilitate  rapid  future  access. 


IMPLEMENTATION 

The  STP  represents  the  best  estimate  of  these 
synergistic  processes  and  their  effects  on  the 
concept  of  operation.  The  result  is  a  system 
which  we  believe  represents  a  flexible  and  viable 
concept  for  TRADES. 

The  PFDB  interrelationship  with  TRADES  will 

facilitate  the  accomplishment  of  TRADES  development, 
and  provide  for  the  systematic  operation  of  the 
system.  The  nature  of  the  PFDB  concept  is  further 
explained  and  documented  in  the  Concept  of  Operation. 
Since  the  PFDB  implementation  is  proceeding  on 
schedule,  TRADES  may  readily  be  incorporated  as  an 
acceptable  portion  of  the  PFDB  with  no  problems 
foreseen  at  this  time. 


CHAPTER  III 


CONCEPT  OF  OPERATION 


SYSTEM  DESCRIPTION 

TRADES  is  a  partially  distributed  data  processing 
system  that  uses  a  mini-computnr  located  at  the 
U.S.  Army  Logistics  Center  and  a  backup  mainframe 
computer  at  the  TRADOC  DPFO.  Remote  access  inter¬ 
active  terminals  and  micro-computers  are  located 
at  TRADOC  materiel  combat  development  activities. 
TRADES  will  be  centrally  managed  and  will  provide 
interactive  access  to  automated  sources  of  RAM 
data  as  well  as  internal  information  and  data 
manip"lation  capabilities  on  an  as-required  basis. 
The  overall  concept  of  TRADES  is  shown  in  Figure 
3-1. 


Figure  3-1.  Generalized  Concept  of  TRADES 
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PURPOSE  OF  TRADES 

The  purpose  of  TRADES  is  to  support  the  TRADOC 

combat  developers  in  their  RAM  responsibilities. 

Tbe^'  specific  1  esponsibilities  are  assigned  by 

the  .apartment  of  the  Army  in  draft  DA  Reg.  702-3 

as  fol  :.ows  • 

1.  Establish  and  maintain  controls  to  insure 
effective  coordination  of  RAM  program  functions 
and  compliance  with  AR  702-3. 

2.  Determine,  in  coordination  with  the  materiel 
developer,  realistic  RAM  requirements  consistent 
with  system  operational  and  support  concepts, 
current  technology,  Army  doctrine,  organization 
and  force  structure,  and  the  Cost  and  Operational 
Effectiveness  Analysis  (COEA). 

Monitor  materiel  development  and  assess  how 
’ell  the  system  has  met  RAM  requirements  as 
demonstrated  during  development  test  (DT) 
and  operational  test  (OT). 

4.  Establish  liaison  with  materiel  developers  to 
assist  with  exchange  of  RAM  datr*  needed  to 
develop  requirements  for  emerging  systems. 

5.  Maintain  a  central  activity  for  the  proper 
statement  and  justification  of  RAM  characteris¬ 
tics  in  materiel  requirements  documents. 

6.  Develop  and  keep  abreast  of  current  progress 
in  RAM  methodology  as  applied  to  combat 
developn.  ;nts. 

7.  Conduct  OT  u  assigned  items  of  materiel  to 
assess  RAM  and  provide  RAM  OT  portion  of 
coordinated  test  program  (CTP). 

8.  Review  requests  for  RAM  waivers  for  non- 
developmental  items  and  recommend  approval 
to  DCSRDA,  when  appropriate. 

9.  Provide  RAM  training  for  combat  developers. 

TRADES  will  facilitate  RAM  training  by  pro¬ 
viding  materials  which  can  be  used  by  the  de¬ 
velopers  of  the  RAM  Course. 
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GENERAL  OBJECTIVES  OF  TRADES 


These  functions  imply  responsibilities  in  the 
entire  life  cycle  process,  including  development, 
procurement,  operations  and  support.  The  following 
are  general  objectives  of  TRADES: 

1.  Support  the  preparation  of  requirement  documents, 
such  as  Letters  of  Agreement  (LOA),  Required 
Operational  Capability  (ROC),  Letter  Requirement 
(LR),  and  Training  Device  Letter  Requirements 

( TDLR ) . 

2.  Assist  monitorship  of  development  and  acquisition 
actions . 

3.  Support  RAM  related  activities  for  test 
planning,  test  reports  and  participation  in 
test  review  and  analysis  actions. 

4.  Assist  in  preparation  for  decision  briefings 
such  as  the  In  Process  Reviews  (IPRs),  Defense 
System  Acquisition  Review  Council  (DSARCs), 
and  Army  System  and  Review  Council  (ASARCs). 

5.  Monitor  performance  of  fielded  items  of 
equipment . 

SPECIAL  OBJECTIVES  OF  TRADES 

The  special  objective  of  TRADES  is  to  provide  a 
system  that  TRADOC  and  its  materiel  proponents  can 
use  to : 

1.  Serve  as  an  interface  system  between  RAM 
source  data  and  RAM  data  users,  facilitating 
the  exchange  of  information  between  these 
communities. 

2.  Locate  and  identify  the  source  of  RAM  data 
based  on  TRADOC  user  requirements. 

3.  Collect,  analyze,  and  validate  RAM  data 
provided  from  data  sources. 

4.  Satisfy  user  requirements  within  realistic 
availability  of  information  provided  by  RAM 
data  sources. 


5.  Retrieve,  process  and  disseminate  RAM  data 

using  units  of  measure  compatible  with  TRADOC 
proponent  requirements. 

AUTOMATION  FUNCTIONS 

As  derived  from  the  SRD  investigation,  source  data 
is  located  in  both  hard  copy  and  automated  data 
bases.  There  is  a  large  diversity  of  RAM  data 
ranging  from  both  current  and  historical  information 
found  throughout  the  life  cycle  process  from 
engineering  and  design  documents  to  field  experience. 
Automated  functions  for  the  varieties  of  data  is 
as  follows: 

1.  Operates  as  a  system,  capable  of  being 
accessed  for  a  nominal  11  hours  a  day. 

2.  Provides  RAM  information  at  the  levels  in  the 
following  areas:  end  items,  major  subsystems, 
selected  components  and  support  and  test 
equipment . 

3.  Stores  and  manipulates  selected  RAM  data 
across  the  entire  life  cycle  such  as  the 
following:  reduced  field  experience  by  user 
mission;  DT,  OT  and  special  test  reports; 
specifications,  contract  and  requirements 
documents. 

4.  Performs  statistical  and  analytical  manipu¬ 
lation  of  data.  This  permits  the  user  to 
analyze  data  on  the  computer  rather  than  off¬ 
line  or  manually.  However,  it  does  not 
preclude  the  performance  of  these  tasks  at 
separate  activities  by  micro-processors  where 
that  capability  exists, 

5.  Establishes  a  "default  value"  for  applicable 
RAM  data  elements  of  Army  materiel.  These 
default  values  are  used  to  respond  rapidly  to 
user  requirements  or  when  a  substantiated 
data  base  is  not  available. 

6.  Provides  interactive  access  terminal  to  RAM 
engineers  for  rapid  accessibility  of  data  and 
sources. 

7.  Provides  quick  response  and  source  identification 
capability  for  the  following  essential  elements 
of  information  (EEIs): 
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a.  Mean  Time  Between  Failures  (MTBF) 

b.  Mean  Time  Between  Operational  Mission 
Failures  ( MTBOMF ) 

c.  Mean  Time  Between  Unscheduled  Maintenance 
Actions  (MTBUMA) 

d.  Probability  of  Mission  Success 

e.  Operational  Availability  (AQ)  (including  SRO) 

f.  Utilization  Rates 

g.  Mean  Time  to  Repair  (MTTR) * 

h.  Maintenance  Ratio  (MR)* 

i.  Administrative  and  Logistic  Downtime  (ALDT)* 

In  addition  to  these  hardware  measures  of  RAM, 
other  available  information  may  be  stored  by  the 
proponent  or  user  on  an  optional  basis. 

RELATIONSHIP  TO  PFDB 

General 

The  objective  of  the  PFDB  System  is  to  provide  an 
efficient  and  accurate  means  of  storing,  processing 
and  disseminating  approved  logistics  planning 
factors  and  related  data  from  a  central  source  for 
use  in  joint/unilateral  service  planning,  force 
development,  logistics  studies,  and  reference 
publications  e.g.,  FM  101-10-1.  These  planning 
factors  encompass  all  classes  of  supply,  maintenance, 
transportation,  services,  and  facilities. 

The  PFDB  is  a  proposed  system  which  is  being 
developed  by  the  Planning  Factors  Management 
Division  (PFMD)  of  the  OAD  at  the  LOGC.  The 
Detailed  Functional  System  Requirements  (DFSR)  was 
completed  in  the  fall  of  1981,  and  PFDB  is  antici¬ 
pated  to  be  fully  operational  by  January  1984. 

This  system  is  described  in  more  detail  in  Chapter 
V  of  the  System  Requirements  Definition  (SRD) 
report.  The  PFDB  will  interface  with  many  organizations 
throughout  the  Army  and  with  some  organizations  of 
other  Services.  The  following  organizations  are 


*By  level  of  maintenance. 


candidates  for  direct  output  report  dissemination 
through  telecommunications:  USAREUR,  FORSCOM,  all 
Army  corps,  CAA,  MTMC,  ADMINCEN,  Aviation  School, 
Quartermaster  School,  and  the  Transportation 
School . 

The  PFDB  may  be  characterized  as  a  partially  dis¬ 
tributed  automated  processing  system  since  it  is 
configured  with  a  dedicated  mini-computer  (estimated 
to  be  the  size  of  a  VAX  11/780)  linked  to  a  mainframe 
(eg.  DPFO's  UNIVAC  1100)  both  accessible  by  a 
number  of  interactive  as  well  as  batch  terminals. 
Central  management  and  control  of  the  planning 
factors  system  will  be  accomplished  by  the  PFMD 
through  the  mini-computer. 

The  MTD  File  will  be  integrated  into  the  Planning 
Factors  Data  Base  System  in  both  hardware  and 
software. 

The  future  PFDB  system  software  will  involve  four 
major  functions  feeding  the  Planning  Factors  Data 
Base.  These  are  collection,  analysis/development, 
and  validation  and  storage.  Likewise,  four  essential 
functions  are  involved  in  providing  credible 
output  from  the  data  base  to  users.  These  are 
retrieval,  development /aggregat ion ,  validation  and 
dissemination.  A  management  function  is  required 
to  assure  effective  and  efficient  operation  of  the 
other  functions. 

The  PFDB  functions  lie  in  five  general  areas: 
data  maintenance,  user  access,  management  information 
support,  data  base  administration,  and  software 
maintenance. 

Four  of  the  five  major  software  processes  contributing 
to  the  production  use  of  the  PFDB  (data  maintenance, 
user  access,  management  information,  and  data 
base  administration)  will  have  a  module  associated 
with  the  process.  Each  of  these  modules  depends 
on  a  general  data  base  management  system. 

Figure  3-2  maps  the  operations  of  the  TRADES  Alterna¬ 
tive  Concept  of  Operation  (ACO)  on  those  of  the 
PFDB  System. 
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Figure  3-2.  Future  PFDB  System  Structure  for  Software 
Organization 

TRADES  is  supported  by  a  centralized  functional 
element  and  automated  data  processing  element. 
Decentralized  functional  and  ADP  operations  may 
also  be  performed  at  user  locations. 

External  Organizational  Interfaces 


Interface  between  the  TRADES  office  and  the 
Planning  Factors  Management  Division  (PFMD)  is 
essential  for  coordinated  development  of  both  the 
TRADES  and  PFDB  System,  i.e.,  software  or  hardware 
developments  may  be  accomplished  mutually,  hence, 
more  cost-effectively.  Further,  interface  is 
required  between  the  TRADES  office,  the  LOGO 
Computing  Center,  and  the  TRADOC  DPFO  to  ensure 
adequate  customer  service  and  computer  (i.e., 
mini-computer,  UNIVAC  1100,  and  telecommunications) 
support  is  maintained.  This  interface  will  also 
ensure  that  TRADES  requirements  in  terms  of  job 
runs,  interactive  service,  protocol,  storage 
requirements,  etc.,  are  coordinated. 


The  other  organizational  interfaces  will  include 
the  organizations  (other  LOGC  Directorates ,  TRADOC 
Schools  and  Centers,  TRADOC  Boards,  and  DARCOM 
activities)  that  interact  with  the  TRADES  either 
as  users  or  sources.  It  is  important  to  note  that 
some  of  these  users  and  sources  requiring  interface 
with  TRADES  also  require  interface  with  PFDB . 

The  operational  concept  includes  a  feature  which 
would  provide  direct  access  to  the  Defense  Technical 
Documentation  Center  (DTIC)  through  the  TRADES 
system.  This  feature  is  incorporated  into  the 
Source  Identification  process,  and  implemented 
through  the  Interface  Module.  TRADES  will  communi¬ 
cate  (upon  request  by  the  user)  through  a  communi¬ 
cation  network  similar  to  Time  Net.  The  user,  in 
effect,  is  patched  through  the  TRADES  system, 
using  Modem  switching  and  automatic  dialing 
software  and  hardware,  and  would  communicate  data 
requirements  directly  to  the  DTIC  computer.  The 
DTIC  computer,  a  UNIVAC  1100/82,  provides  directory 
service  to  thousands  of  documents  which  are  of 
potential  importance  to  the  RAM  engineer;  i.e., 
most  OTEA  and  TECOM  test  reports. 

TRADES  OPERATING  MODULES 

The  basic  TRADES  system  concept  includes  five 
modules  which  are  controlled  by  a  master  TRADES 
executive  program.  These  modules  (shown  in  Figure 
3-3)  include: 

1.  Source  Identif ication 

2.  Interface 

3.  Quick  Response 

4.  Statistical/Analytical 

5.  Management 

Their  description  anu  data  content  are  explained 
in  succeeding  paragraphs. 


Source 

Identification 


Figure  3-3.  TRADES  System  Concept  Modules 


Source  Identification  Module 


This  module  is  the  basic  vehicle  by  which  RAM  data 
users  can  query  a  central  repository  for  all 
sources  of  appropriate  RAM  data.  It  contains  a 
logical  organization  or  taxonomy  of  all  commodities 
of  interest  to  RAM  data  users,  to  the  end  item, 
major  system  or  subsystem  levels.  Selected  components 
and  support  and  test  equipment  may  also  be  entered 
as  required.  This  module  provides  the  user  with: 

1.  Agency  and/or  activity  with  appropriate  RAM 
data  holdings 

2.  Form  of  data  (hard  copy,  automated  unclassified 
and/or  secure  data  bases) 

3.  Extent  of  holdings  (years  of  information, 
number  of  test  reports,  total  number  of 
records,  etc.) 

4.  Form  of  data  (test  reports,  raw  field  data, 

reduced  data,  analysis  results,  etc.) 

5.  Environmental  conditions  (e.g. ,  peacetime 

versus  combat,  geographical  area,  arctic 
versus  tropical,  desert  versus  cultivated 
areas ,  etc. ) 

6.  Point  of  contact 

7.  If  automated  data  base: 

a.  Accessibility  through  user  terminal 

b.  Necessary  passwords,  machine  interface, 
baud  rate,  etc, 

c.  Protocol  and  procedures  for  obtaining  data. 

In  the  event  that  an  automated  data  source  is 
identified  in  query,  this  module  provides  complete 
description  of  file  layouts,  EEIs  in  each  field  of 
data,  together  with  necessary  identification  and 
definition  of  terminology  to  provide  the  user  with 
information  relative  to  user  requirements  which 
may  be  matched  by  the  data  base. 


Interface  Module 


This  module  contains  the  necessary  protocol  to 
communicate  with  the  diverse  computers  which  may 
contain  RAM  data  bases  within  DA  (or  other  military 
services,  as  required).  Access  to  the  interface 
module  is  indicated  from  the  source  identification 
module,  depending  on  the  specific  usei  requirements 
and  source  identification.  To  the  extent  feasible, 
this  module  also  contains  adequate  software  to 
provide  the  user  with  a  basic  vehicle  for  extracting, 
analyzing,  and  formatting  outputs  from  automated 
data  sources. 

Quick  Response  Module 

This  module  provides  an  immediately  accessible  value 
for  each  applicable  EEI  (and  the  conditions  under 
which  it  was  derived)  for  the  system.  These  values 
represent  the  best  technical  estimate  for  the  EEIs 
based  on  all  available  data  for  the  system.  The  val¬ 
ues  contained  in  the  Quick  Response  Module  are  updated 
by  the  TRADOC  proponent  agency  upon  the  availability 
of  more  current/more  accurate  data  as  the  system  pro¬ 
gresses  through  the  life  cycle. 

Statistical/Analytical  Module 

The  purpose  of  the  Statis+ical/Analytical  Module 
is  to  facilitate  the  preparation  of  RAM  statistics, 
perform  tests  of  hypotheses,  to  determine  whether 
the  effect  discerned  is  due  to  chance,  whether 
there  are  trends,  and  to  assess  the  stability  of 
observations. 

Computations  and  methodology  which  may  be  a  part  of 
TRADES  are  the  following: 

1.  Analysis  of  variance 

2.  Analysis  of  covariance 

3.  Data  Transformations 

4.  Distributions  and  Processes 

a.  Normal 

b.  Binomial 

c .  Gamma 

d.  Chi-Square 

e.  Weil  all 
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f.  Log  Normal 
g>  Exponential 
h ■  Poisson. 

5.  Utility  Routines 

a.  Matrix  operations  (e.g.,  inversion) 

b.  Plotting 

6.  Time  Series  Analysis 

7.  Descriptive  Statistics  (Curve-fitting, 
Central  Tendency  and  Moments) 

8.  Regression  (univariate  and  multivariate) 

9.  "Interactive"  Data  Analysis. 

10.  RAM  Rationale Annex  Handbook  Methodology 

Management  Module 

This  module  provides  the  key  tool  for  the  TRADES 
users  and  managers  to  manage  the  TRADES  system. 
Its  primary  functions  are: 

1.  Provides  a  basis  for  updating  and  developing 
the  other  modules  on  a  regular  basis 

2.  Provides  an  audit  trail  of  actual  TRADES 
utilization,  and 

3.  Provides  the  proponents  with  a  method  to 
record  procedural  notes  for  later  access 
(i.e.,  provides  an  audit  trail  of  RAM 
ground  rules). 


Estimated  Volume 

A  total  of  89  megabytes  of  on-line  storage  is  esti¬ 
mated  for  the  TRADES  System  (see  Table  3-1).  This 
is  based  on  the  following  tables  (3-2  to  3-5)  and 
calculations,  based  on  approximately  1,000  end  items 
under  development  currently,  and  expansible  to  10,000 
lines  of  material  with  RAM  significance.  When  TRADES 
is  extended  to  all  10,000  possible  RAM  significant 
items,  total  file  sizes  may  exceed  cost-effective 
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on-line  storage  capacity  of  the  computer  system. 
At  that  time,  consideration  can  be  given  to  off¬ 
line  storage  of  low  priority  item  RAM  records. 
Available  tape  drives  can  be  used  to  "hang"  the 
appropriate  storage  tape  on-line  when  queries  are 
received  for  the  low  priority  records. 


TABLE  3-1.  TRADES  MODULE  FILES 
-  SIZE  FORECAST 


MODULE 

FORECAST  SIZE 
( Bi ts ) 

o  Source  Identification 

Module 

54.0 

o  Quick  Response  Module 

30.5 

o  Interface  Module 

2.5 

o  Management  Module 

1.0 

o  Statistical/Analytical 

Module 

>  -5 

■  " 

TOTAL 

88.5 

■  i  .  .  ■■  — - ....  . . 

TABLE  3-2.  SOURCE  IDENTIFICATION  ENTRY 


ELEMENT 

AVERAGE 

CHARACTERS/RECORD 

Agency/Activity 

240 

Automated  or  Hard  Copy  Classification 

10 

Extent  of  Holdings 

-  Years,  Reports,  Records 

50 

Form  of  Data 

50 

Environmental  Conditions 

50 

Key  Words  and  EEIs  Applicable 

500 

Abstract 

600 

Accessibility  for  Automated  Data  Base 

500 

TOTAL 

2,000 

TABLE  3-3.  SOURCE  IDENTIFICATION  MODULE  FILE  SIZING 


MAIN 

DATA  AREA 

AVERAGE 
#  OF 
REPORTS 

— 

TOTAL 

REPORTS 

#  OF 

CHARACTERS 

MEGA¬ 

BYTES 

End  Items 

1 ,000 

4 

4,000 

2,000 

8 

Subsystems 

3,000 

4 

12,000 

1 ,000 

12 

Components 

15,000 

2 

30,000 

1 ,000 

30 

Test  &  Spt. 

1,000 

2 

2,000 

2r0C0 

4 

TOTAL 

20,000 

54 

NOTE:  For  all  references  to  sizing,  one  character  is  equal  to  one  byte. 


TABLE  3-4.  QUICK  RESPONSE  ENTRY 


AVERAGE  SIZE 


ELEMENT 

OMS/MP 

FD/SC 

Life  Cycle  Stage 
Distribution 

Total  Incidents  Experienced 
(5  per  EEI ) 

Sample  Size 
(6  per  EEI) 

Environment 

Time  Breakdown 

TOTAL 


(Characters) 

200-2000 

800-8000 

5 

20 

40 

i 

48 

50 

48 

1,200  -  10,211 


L 


TABLE  3-5.  QUICK  RESPONSE  MODULE  FILE  SIZING 


MAIN 

DATA  AREA 

ESTIMATED 

QUANTITIES 

i 

CHARACTERS 

MEGABYTES 

End  Items 

1 ,000 

10,000 

10.0 

Subs> stems 

3,000 

1 ,000 

3,0 

Components 

15,000 

1  ,000 

15.0 

Test  &  Support 

1 ,000 

2,500 

2.5 

TOTAL 

20,000 

30.5 

AUTOMATED  RAM  DATA  REFERENCES 


At  present,  a  certain  amount  of  RAM  data  is  being 
stored  in  automated  data  systems.  However,  with 
the  near  implementation  of  CTDCS  and  the  future 
consideration  of  SAMS,  increasingly  larger  portions 
of  RAM  data  will  become  available  from  these 
automated  data  systems.  Accordingly,  TRADES 
recognizes  two  »  otential  conditions  relative  to 
automated  source  data  bases: 

1.  RAM  data  resident  on  a  large-scale  computer 
system  with  interactive  software  capability, 
where  a  user  can  select  certain  data  and  be 
provided  an  analyzed  output  format. 

2.  An  automated  data  base  which  is  principally  a 
repository  of  RAM  information  with  little  or  no 
interactive  software  capability. 

If  condition  1.  prevails,  the  TRADES  interface 
module  will  structure  specific  requirements  which 
can  then  be  processed  on  a  resident  computer.  The 
product  would  be  an  output  report ,  either  hard 
copy  mailed  or  on-line  printed  through  a  high-speed 
printer,  of  a  product  directly  usable  by  RAM  engineer 

In  condition  2.  above,  the  overall  TRADES  computer 
system  must  have  provision  for  data  extraction 
programs  and  all  of  the  associated  software  to 
process  the  information  into  usable  form  by  appli¬ 
cation  of  the  statistical/analytical  module  in  the 
TRAPES  computer.  In  parallel  with  this  is  the 
requirement  for  the  TRADES  computer  to  extract  the 
necessary  elements  of  data  from  the  resident 
data  bank  and  store  the  information  temporarily 
during  the  processing.  The  output  would  be 
a  direct  product  of  the  user  via  the  TRADES  terminal, 
£  id  peripheral  high-speed  printers. 

A  third  alternative  may  be  used  when  the  user  has 
a  relatively  large  capacity  computer  available. 

Here,  TRADER  could  make  provision  to  extract  relevant 
data  fields  from  the  resident  RAM  data  base,  and 
provide  the  data  alements  to  the  user's  computer 
facility.  Likewise,  temporar;  storage  of  pertinent 
information  for  futui r  use  is  possible.  In  such 
event,  the  end  results  must  be  entered  into  the 
historic? 1  module,  if  the  system  is  not  to  "hemorrhag 


CATEGORIZATION  OF  DATA  FILES 


Storage  Location 

The  data  files  will  generally  be  in  three  locations: 

The  principal  location  of  mass  storage  (shown  in 
Figure  3-4)  will  be  on  the  PFDB/TRADES  mini¬ 
computer  located  in  the  LOGC  Computing  Center  at 
Fort  Lee,  Virginia.  Both  on-line  and  off-line 
storage  capabilities  are  recommended  for  prompt 
user  response  and  archival  storage  respectively. 
Disk,  tape,  or  card  storage  are  adequate  for 
TRADES  based  on  the  response  time  requirements 
established  previously.  However,  interactive 
requirements  will  require  disk  operations  and 
requisite  CPU  memory  capacity.  (The  TRADES  mini¬ 
computer  should  be  capable  of  accommodating  I., 
optical  disk  for  archival  storage  as  it  becomes 
available  in  the  near  future.)  Storage  will  be 
sufficient  for  interactive  use  of  up  to  40  users 
and  Data  Base  Management  System  (DBMS)  operations. 

The  second  area  for  both  on-line  and  off-line 
storage  is  at  the  TRADOC  DPFO.  The  UNIVAC  1100 
should  have  sufficient  storage  for  the  TRADES 
systems  for  both  interactive  and  batch  operations 
for  up  to  40  users  (providing  back-up  and  safety). 

The  third  location  for  storage  will  be  at  the  user 
terminal.  It  is  anticipated  that  many  users  will 
have  local  storage  capability.  (Currently  available 
micro-computers  and  terminals  have  reasonably  low 
cost  storage  capability  in  the  form  of  floppy 
disks  or  magnetic  tape  cartridges. )  User  unique 
programs,  results,  and  local  working  RAM  information 
is  anticipated  to  be  stored  at  this  location. 
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Figure  3-4,  TRADES  Alternative  Concept 

of  Operation  (ACO)  Using  PFDB  System 


Source 


The  contents  of  the  data  base  will  come  from  a 
wide  variety  of  sources.  Information  for  the 
Quick  Response  Module  will  be  entered  by  the  pro¬ 
ponent  activity,  from  engineering,  test  and  field 
data.  This  data  may  be  either  entered  directly 
utilizing  routine  management  update  procedures,  or 
captured  upon  completion  of  a  statistical  manipulation 
of  raw  data  provided  by  external  data  sources. 

A  detailed  listing  of  data  sources  is  provided  in 
Chapter  IV  of  the  SRD.  The  data  sources  are  in  a 
wide  diversity  of  substance  and  format,  and  with 
the  exception  of  the  high  use  common  systems,  are 
frequently  filed  in  locations  off-line.  The  Source 
Identification  Module  catalogs  these  data  sources, 
along  with  known  information  (both  automated  and 
hard-copy),  and  makes  their  availability  known  to 
users  as  required.  The  information  for  these 
purposes  will  be  provided  by  data  sources  on  a 
regular  basis,  upon  a  periodic  review  and  request 
for  information  by  the  TRADES  management  office. 
Additionally,  DTIC  information  will  be  available 
on-line  using  through-put  procedures  through 
TRADES . 

Mode  of  Access 

The  mode  of  access  to  the  TRADES  system  will  be 
manual  and  through  interactive  terminals  and  batch 
processing. 

Manual  Mode 

For  those  users  who  do  not  have  terminals  (estimated 
to  be  about  50%  in  SRD),  solicitation  for  RAM  data 
and  analysis  products  will  be  made  by  mail  or 
telephone  calls  to  the  TRADES  office  until  all  users 
have  access  to  (or  are  provided  with)  a  terminal. 

The  additional  staff  recommended  previously  will 
be  sufficient  to  handle  the  initial  load  (growth 
in  number  of  users  in  the  future  may  necessitate 
additional  personnel). 


3-19 


Interactive  Terminal  Operations  Mode 


Those  users  with  computer  terminal  equipment  can 
access  TRADES  directly  on  the  PFDB-TRADES  mini¬ 
computer  located  in  the  LOGC  Computing  Center  or 
UNIVAC  1100/82  time  sharing  mainframe  at  DPFO, 

Fort  Leavenworth  via  normal  telephone  lines  (phone 
numbers  will  be  assigned  by  DPFO  and  the  LOGC 
Computing  Center  to  appropriate  computer  access 
ports) . 

Normal  "log  in"  procedures  to  access  the  mini¬ 
computer  or  the  mainframe  will  be  used  to  interact 
wixh  TRADES. 

For  users  who  have  computer  terminals  and  secure 
link  capability,  access  is  gained  with  procedures 
similar  to  those  described  above  for  unclassified 
users. 

Batch  Operations  Mode 

Batch  runs  will  be  made  principally  through  the 
TRADES  office.  However,  it  is  anticipated  that 
both  the  Planning  Factors  Management  Division  and 
LOGC  Computing  Center  at  Fort  Lee  will  be  able  to 
accommodate  "batch"  requests  from  users  for  TRADES 
inputs  or  outputs.  Users  with  or  without  terminals 
may  use  this  capability. 

End  Products  Description 
Format : 

Two  types  of  end  products  will  be  available  through 
TRADES.  The  first  will  be  formatted  in  a  form 
suitable  for  interactive  queries.  For  example, 
where  an  interactive  query  is  "M60A1  Tank  reports 
in  OT  I?"  the  output  may  be: 

"M60A1  Tank  Reports  =  OTEA  REPORT  OT  I" 
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The  other  type  of  end  product  will  be  the  fixed 
report.  In  special  cases  where  information 
is  required  by  users  on  a  routine  basis,  it  is 
more  practical  to  produce  a  formatted  report  or 
table  of  values  rather  than  a  few  data  points  per 
query. 

For  example,  for  a  query,  "Print  OTEA  Test  Report 
on  M60A1  OT  I,"  the  predetermined  and  formatted 
output  would  be  in  report  or  tabular  form  with  a 
number  of  essential  data  being  displayed. 

Interface  between  Users/Data  Sources/Automated  Systems 

The  principal  interface  between  users  and  data 
sources  or  other  automated  systems  containing  RAM 
information  is  through  the  TRADES  "Interface" 

Module . 

TRADES  will  become  the  primary  interface  mode 
between  the  users  of  TRADES,  primarily  TRADOC,  and 
the  sources  of  RAM  information,  primarily  DARCOM. 

The  TRADES  system  will  create  a  free  exchange  of 
information  and  facilitate  the  ability  of  the  user 
to  rapidly  locate  and  acquire  RAM  data. 

This  effort  will  be  done  primarily  in  the  following 
manner.  Known  data  sources  will  be  categorized 
and  placed  in  a  logical  order  for  use  in  the 
Source  Identification  Module.  This  logical  order 
or  taxonomy,  should  be  based  on  the  TM  38-750 
breakout  of  equipment.  Wherever  possible,  subsystems 
and  components  will  be  identified  and  ordered  in 
such  a  manner  to  provide  for  cross-referencing 
similar  components  or  subsystems  between  end 
items.  This  taxonomy  will  be  provided  to  all 
users  for  access  during  inquiry  procedures. 

Information  catalogued  by  DTIC  will  be  available 
on-line  through  TRADES. 

TRADES  will  provide  the  user  query  with  information 
on  the  location  of  source  data  (See  Figure  3-5). 

The  user  then  proceeds  with  obtaining  the  data, 
either  interactively  if  from  another  automated 
source,  by  off-line  follow-up  for  hard  copy 
requirements,  and/or  by  information  stored  in  the 
Quick  Response  Module. 
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MANAGEMENT 

MODULE 


Review  Quick 
Response  File 
&  Corporate 
History  Files 


Recommend 
updates  to 
proponents 


Review  TRADES 
Util'n.  and  Service, 
&  Corporate 
History  Files 


-Add,  delete,  change 
Interface  Module 
software,  as  req'd. 

-Add,  delete  EEIs, 
as  req'd. 

-Add,  delete,  change 
references  to 
Source/Identi fication 
Module,  as  req'd. 

-Add,  change,  improve 
Statistical /Analytical 
Module,  as  req'd. 


Figure  3-6.  TRADES  Management 
Functions 


Upon  obtaining  data  required  and  performing  desired 
statistical  manipulations,  the  user  may  then 
temporarily  store  selected  information  in  TRADES 
using  shorthand  notes  or  off-line  storage.  If  the 
user  is  the  proponent  for  a  given  report,  that 
information  may  be  stored  in  the  Quick  Response 
file  for  access  by  other  users.  (See  Figure  3-6). 

The  TRADES  office  will  conduct  periodic  updates 
and  surveys  of  data  sources  to  ensure  that  all 
relevant  data  sources  are  identified  and  acknowledged 
for  entry  into  the  Quick  Response  file. 

Table  3-6  addresses  the  most  frequent  automated  sources 
of  RAM  data  expected  to  be  used  and  made  available. 

Of  particular  significance  to  a  thorough  under¬ 
standing  of  system  operations  are  Chapters  IV, 

V,  and  VII,  which  detail  the  internal  operating 
characteristics,  the  external  operating  character¬ 
istics,  and  the  TRADES  software  requirements. 


TABLE  3-6  .  KEY  DATA  SOURCES* 


f  Y-WIDE  RAM  SOURCES 

COMMODITY  ORIENTED  SOURCES 

LSAR 

RAM/ LOG 

TECOM 

TAIDB 

CTDCS 

VETMIS 

DRS 

SATCOM 

TELIS 

COMu 

t 

TAERS/TAMMS 

SDC 

SAMS 

MTD 

NUCWEP 

♦Reference  APJ  Report  892-2,  "TRADOC  RAM  Data 
Evaluation  System  (TRADES)  (ACN  51235) 

-  System  Requirements  Description"  for 
descriptions  and  definitions 


CHAPTER  IV 


INTERNAL  OPERATING  CHARACTERISTICS 


GENERAL 


The  purpose  of  this  chapter  is  to  provide  a  clear, 
detailed  description  of  the  internal  operations  of 
the  proposed  system.  The  chapter  will  describe 
techniques  for  data  retrieval,  data  processing, 
and  data  dissemination.  This  chapter  also  contains 
flowcharts  which  form  a  basis  for  functional 
understanding  of  the  system,  but  are  not  detailed 
enough  to  permit  software  programming.  This 
chapter  also  describes  procedures  for  acquiring, 
verifying  and  storing  data.  (Definition,  design, 
and  programming  activities  for  TRADES  will  occur 
in  the  later  life  cycle  stages  of  TRADES).  In 
addition  to  this  chapter,  a  thorough  review  of 
Chapter  VII,  Software  Requirements,  is  highly 
recommended  for  a  complete  understanding  of  the 
internal  operations  of  TRADES. 

TRADES  DATA  ACQUISITION  VERIFICATION  AND  STORAGE 

TRADES  acquires,  verifies  and  stores  information  for 
five  principal  reasons: 

1.  To  identify  sources  of  RAM  data  (Source 
Identification  Module). 

2.  To  identify  RAM  values  for  end  items,  subsystems, 
components  and  test  and  support  equipment 
(Quick  Response  Module). 

3.  To  access  information  stored  in  other 
data  banks  (Interface  Module). 

4.  To  facilitate  data  manipulation  and  computation 
by  the  RAM  Engineer  (Analytical/Statistical 
Module). 

5.  To  provide  management  information  for  the  storage 
and  utilization  for  TRADES  management  as  well 

as  the  individual  RAM  engineer  computations  for 
historical  purposes  (Management  Module). 

Each  of  these  TRADES  acquisition  processes  (modules) 
are  described  in  turn: 


Source  Identification  Module 

Information  for  source  identification  is  acquired 
primarily  by  off-line  processes,  and  then  entered 
into  the  TRADES  system  by  the  TRADES  Management 
Branch  on  an  interactive  or  batch  input  process. 

This  update  of  information  can  occur  either  on  an 
"as  available"  basis  or  during  periodic  management 
update  routines.  Data  sources  should  be  fully 
identified  in  accordance  with  the  file  content 
specified  in  Chapter  3  of  the  STP.  The  data 
system  will  permit  change  at  any  time.  However, 
the  record  of  this  change,  addition  or  deletion  to 
the  Source  Identification  Module  will  likewise  be 
recorded  in  the  History  Section  of  the  Management 
Module,  and  permanently  filed  using  Off-line  storage 
when  retired  and  archivized  (See  Figure  4-1). 

Verification  procedures  are  dependent  upon  the 
TRADES  Management  Branch  to  review  sources  and 
reduce  appropriate  references  to  the  Source 
Identification  Module  format.  Proponents  would 
have  a  significant  responsibility  in  the  review  of 
sources  identified  for  their  area  of  interest,  and 
recommendations  to  add  or  delete  references  accordingly. 

Internal  verification  procedures  are  limited  to 
entry  formatting  and  standard  techniques  for  edit 
routines  based  on  expected  alpha  or  numeric  entries. 

Storage  of  sources  identified  for  potential  use 
will  be  in  the  active  TRADES  system,  probably  on¬ 
line  disc  storage,  with  changes  to  the  file  placed 
in  the  on-line  Management  Module,  and  eventually 
retrieved  after  periodic  update  routines  have  been 
completed. 

Quick  Response  Module 

The  rapid  identification  of  RAM  values  for  all 
levels  of  RAM  data  is  updated  in  several  ways. 

The  proponent,  upon  performing  a  calculation  or 
obtaining  results  from  a  test,  will  enter  this 
information  into  the  system  on  the  same  basis  as 
described  above,  (either  "as  required  and  developed" 
or  during  periodic  management  update  routines). 

This  may  be  done  interactively  by  the  proponent 
user,  or  by  providing  the  information  by  card, 
tape  or  manual  means  to  the  TRADES  Management 


V.V.MM'-'VV  V -.1  Vrvr:.v.^w;-1  *\  , 


Figure  4-2.  Internal  Operating  Concept,  Acquisition, 
Verification  and  Storage 
-  Quick  Response  Module 


Storage  of  these  values  are  in  the  Quick  Response 
Module,  which  is  in  c:i-line  disk  storage.  The 
record  of  change  would,  however,  be  filed  in  the 
historical  section  of  the  Management  Module  and 
subsequently  retired  on  off-line  tape  storage. 

Interface  Module 

Data  information  for  accessing  automated  information 
systems  on  an  interactive  basis  will  be  stored  on 
the  Interface  Module  of  the  TRADES  system.  Initial 
coordination  with  the  common  sources  of  RAM  data 
will  be  necessary  to  program  the  Interface  Module 
for  automated  interface  with  data  sources.  It  will 
be  necessary  for  the  TRADES  Management  Branch  to 
remain  cognizant  of  all  access  procedures  changes 
provided  by  the  host  data  source.  This  will  be 
done  on  an  automatic  basis  by  being  on  the  customer 
list  for  the  host  automated  system,  or  other 
method  of  monitoring  updating  procedures  specified 
by  that  host  system. 

A  common  method  of  updating  will  be  to  respond 
whenever  the  standard  interface  module  fails 
to  achieve  interactivity.  In  this  event,  the 
TRADES  Senior  Programmer  in  PFMD  must  coordinate 


Standard  verification  procedures  such  as  checks 
and  length  of  fields  will  provide  the  TRADES 
programmer  with  information  relative  to  the  validity 
of  the  information  transfer,  and  thus  the  validity 
of  the  interface  program  itself. 

The  interface  procedures  will  be  stored  on-line  as 
the  Interface  Module  and  will  be  changed  in  response 
to  the  Senior  Programmer.  Historical  files  are 
not  required  for  storing  these  changes  permanently. 


Statistical /Analytical  Module 


The  method  of  acquiring  information  from  other 
data  banks  for  use  in  TRADES  is  variable,  and 
depends  on  the  relative  capabilities  of  TRADES  and 
the  host  system.  The  typical  method  will  first 
require  off-line  coordination  between  the  proponent 
and  the  TRADES  Management  Branch.  After  coordination 
of  data  requirements  with  the  data  sources,  appropriat 
entry  into  the  source  data  system  will  be  made  by 
the  TRADES  system  through  communication  devices. 

Where  this  is  done  on  a  routine  and  recurring 
basis,  a  series  of  interfacing  software  programs 
will  already  be  available  and  will  provide  for 
rapid  entry  on  an  interactive  basis  as  indicated 
above.  However,  data  may  also  be  provided  by  a 
source  using  tape  or  cards  as  available. 

Information  acquired  from  these  data  sources  and 
through  the  Interface  Module  will  be  placed  into 
Central  Processing  Unit  (CPU)  memory  for  necessary 
manipulation  or  storage  actions  as  required.  (See 
Figure  4-4).  Verification  of  data  received  from 
these  sources  is  subject  to  the  same  procedures  as 
described  previously.  Additionally,  "credibility 
checks"  for  gross  outliers  may,  of  course,  be 
automated. 


Figure  4-4,  Internal  Operating  Concept,  Acquisition, 
Verification  and  Storage 
-  Statistical/Analytical  Module 
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The  various  routines  in  this  module  are  applied  to 
information  in  the  CPU  as  necessary.  The  functions 
of  analysis  remain  on-line  in  disk  storage  as  the 
Statistical/Analytical  Module.  Additional  a  \alytical 
procedures  may  be  added  as  required  to  this  module 
through  the  TRADES  Management  Branch. 

Computations  made  by  RAM  engineers  will  be  stored 
in  total,  or  summarized  as  shorthand  notes  for 
retrieval  as  necessary  in  the  management  module. 

Management  Module 

Management  information  and  data  are  acquired 
through  the  automatic  monitoring  and  recording  of 
computer  activity  that  occurs  within  the  TRADES 
system.  The  normal  process  is  done  on  a  routine 
basis,  which  includes  identifying  and  recording 
the  user,  module  used,  and  total  CPU  time.  Other 
data  included  at  the  proponent's  option  will  be 
entered  upon  command  using  interactive  entry  or 
batch  process  by  the  proponent  (or  TRADES  Management 
Branch)  on  an  "as  determined"  or  periodic  management 
update  process.  Storage  of  data  is  a  distinct 
function  of  the  Management  Module,  and  has  been 
illustrated  in  Figures  4-1  through  4-4.  Essential 
information  acquired  is  thus  a  highly  significant 
tool  for  management  of  the  TRADES  system  by  the 
TRADES  Management  Branch. 

DATA  RETRIEVAL,  PROCESSING  AND  DISSEMINATION 

Data  Retrieval 


A  vital  function  of  TRADES  is  to  rapidly  retrieve 
data  from  within  the  TRADES  system,  or  from  other 
systems  on  an  automated  basis.  The  discussion 
above  dealt  with  data  retrieved  from  other  data 
banks.  This  discussion  is  limited  to  retrieval 
methods  for  data  already  available  within  TRADES. 

TRADES  is  accessible  to  the  user  either  through 
the  PFMD  mini-computers  or  direct  to  the  computer 
at  DPFO.  The  procedure  for  this  would  direct  the 
user  to  use  primarily  the  mini-computer  at  the 
LOGC  in  the  first  instance.  In  the  event  that 
processing  is  not  possible  due  to  saturation  of 
the  computers  at  the  LOGC,  the  user  will  be  directed 
to  access  DPFO. 

Updating  of  files  between  the  PFMD  and  DPFO  computers 
will  be  performed  automatically  on  a  daily  basis 
or  whenever  the  computer  is  reinitialized  after  a 
period  of  downtime  (See  Figure  4-5.) 
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Figure  4-5. 


Procedure  for  Backup  of 
TRADES  System  by  DPFO 


Processing 


Processing  data  performance  is  identical  at  both 
PFMD  and  DPFO.  The  software  will  be  written  to 
ensure  that  TRADES  is  usable  on  both  (or  any  large 
capacity  computer),  to  ensure  the  portability  of 
the  system  and  provide  necessary  safety  and  back-up. 

Dissemination  Techniques 


Reports  and  information  are  provided  in  a  number 
of  different  ways.  Specific  data  element  responses 
are  provided  interactively  at  the  CRT  and  the 
side-by-side  line  printer  if  d  sired,  or  by  magnetic 
tape  or  card  output.  More  voluminous  responses 
would  be  provided  through  high  speed  line  printers 
available  at  all  TRADOC  installations. 

Reports  may  also  be  mailed  <:o  users  who  do  not 
have  computing  capability.  The  TRADES  Management 
Branch  will  serve  as  the  initial  point  of  contact 
for  this  service  and  any  other  customer  requirements 
relating  to  the  dissemination  of  information. 


SUMMARY 


This  chapter,  in  conjunction  with  Chapter  VII, 
Software  Requirements,  provides  the  essential 
internal  operating  characteristics  of  TRADES. 
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CHAPTER  V 


EXTERNAL  OPERATING  CHARACTERISTICS 


ELEMENTS 


The  primary  external  activities  of  the  TRADES 
system  may  be  categorized  into  four  categories, 
each  with  a  portion  of  the  responsibility  for  the 
operation  of  the  TRADES  syscem.  These  elements 
are  all  contributors  to  the  TRADES  system  when 
viewed  in  its  larger  sense  and  are  categorized  as: 
Users,  TRADES  functional  element,  TRADES  data 
processing  element,  and  data  sources,  as  shown  in 
Figure  5-1, 


USERS 

TRADES  MANAGEMENT  BRANCH 
TRADES  DATA  PROCESSING  ELEMENT 
EXTERNAL  DATA  SOURCES 


Figure  5-1.  TRADES  System  Parcicipants 
PARTICIPANT  DEFINITIONS 
User 

A  user  is  an  activity,  normally  located  in  TRADOC, 
whose  responsibilities  include  the  determination 
of  RAM  characteristics  for  the  combat  development 
process,  as  specified  in  AR  702-3  (with  TRADOC 
supplement)  and  other  related  combat  development 
materiel  responsibilities.  Anticipated  users  are 
listed  in  Appendix  D  to  the  SRD. 

TRADES  Management  Branch 

This  activity  provides  TRADES  system  management, 
methodological  and  analysis  support,  and  source 
and  u^er  functional  area  customer  assistance. 

TRADES  Data  Processing  Element 

This  function  incorporates  the  responsibility  for 
programming  changes,  special  ADP  manipulation,  as 
required  by  TRADES  users  and  the  TRADES  functional 
elements  to  include  management  and  use  of  the 
interface  module  for  extraction  of  unique  data 
requirements  from  data  sources. 
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External  Data  Sources 


Activities  such  as  the  Material  Readiness  Support 
Activity  (MRSA),  or  the  Operational  Test  &  Evalua¬ 
tion  Agency  (OTEA),  among  many  others,  provide  RAM 
related  information  to  TRADES.  Examples  of  infor¬ 
mation  systems  which  provide  this  data  for  fielded, 
design  and  test  environments  are  SAMS,  LSAR,  and 
COMRAM.  Sources  of  data  and  their  activities  are 
listed  in  Table  3-3  of  the  SRD  and  portray  the  com¬ 
mon  relationships  between  users  and  sources.  Data 
sources  are  described  in  detail  in  Chapter  IV  of 
the  SRD. 


FUNCTIONAL  USERS  RESPONSIBILITIES 

It  is  envisioned  that  TRADES  users  in  TRADOC  will 
have  both  a  "use"  function  and  a  "control"  function. 
User  activities  are  staffed  with  RAM  functional 
personnel  and  are  located  in  TRADOC  integrating 
centers,  schools,  test  boards,  and  in  the  RAM/ILS 
Division  of  the  Materiel  Systems  Directorate,  U.S. 
Army  Logistics  Center.  Personnel  in  the  RAM 
offices  of  the  TRADOC  schools,  centers,  boards, 
and  TSMs  support  TRADES  in  areas  for  which  they 
are  the  proponents.  These  responsibilities  are: 

1.  Update  of  the  Quick  Response  Module  files  for 
values  for  which  they  are  the  proponent . 

2.  Customer  Service  and  Assistance,  for  support 
primarily  to  activities  within  these  locations 
or  span  of  responsibilities. 

3.  RAM  Analysis,  for  requirements  documents  and 
fielded  developmental  items  within  the  RAM 
engineer's  mission. 

Additional  personnel  must  be  authorized  in  some 
cases  for  this  system  and  are  described  in  Chapter 
VI  of  the  STP.  In  all  cases,  it  is  imperative 
that  user  personnel  be  trained  and  familiar  with 
the  capabilities  of  the  TRADES  system.  The  system 
is  designed  to  be  "user  friendly",  but  does 
presuppose  some  familiarity  with  RAM  terms  and 
procedures. 
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User  Procedures 


When  a  requirement  for  RAM  data  is  identified,  the 
user  queries  the  Source  Identification  Module  in 
terms  of  a  specific  EEI  for  an  end  item,  subsystem, 
component,  or  support  and  test  equipment.  This 
can  be  further  delineated  by  geographical  conditions, 
local  environments,  and  type  of  data,  e.g.,  DT,  OT, 
or  field. 

This  inquiry  may  be  performed  by  direct  interactive 
terminal  capability  to  the  TRADES  system.  Secondary 
methods  of  telephone  inquiry  or  mail  are  also 
authorized  (See  Figure  5-2). 

The  information  inquiry  is  received  by  the  TRADES 
system,  and  a  response  prepared  by  the  computer  in 
accordance  with  the  requested  information.  If  the 
response  is  handled  on  an  interactive  basis,  which 
assumes  the  user  has  an  inquiry  device  such  as  a 
terminal,  there  will  be  an  immediate  response, 
depending  upon  queueing  at  the  TRADES  computer. 

A  series  of  interactive  queries  with  the  computer 
will  narrow  down  the  sources  for  appropriate  RAM 
information.  Further,  the  user  may  be  "patched 
through"  the  TRADES  system  and  placed  on  line  with 
the  Defense  Technical  Documentation  Center  (DTIC) 
computer.  Queries  and  responses,  using  the  DTIC 
key  words  v/ill  then  be  begun  and  choices  narrowed 
down  accordingly. 

Based  on  the  responses  received  and  the  selection 
process  of  the  RAM  Engineer,  requests  for  hard 
copy  information  may  be  performed  off-line,  RAM 
information  requested  and  received  from  the  TRADES 
Quick  Response  Module,  or  a  request  made  for 
information  from  an  automated  data  source.  These 
steps  are  graphically  shown  in  Figure  5-3.  If  no 
data  sources  are  identified,  the  user  may  proceed 
off-line  with  a  request  for  assistance  by  the 
TRADES  Management  Branch. 

If  information  is  available  for  hard  copy  sources, 
the  types  of  information  provided  by  TRADES  will 
be : 

1.  Title,  Date,  Issuing  Activity 

2.  Location 


3. 


Abstract 


Figure  5-3.  Inquiry  for  RAM  Data  Sources 


4.  POC/Name/Telephone  No. 

5.  Address 

6.  Instructions  to  obtain  document. 

The  user  will  proceed  with  ordering  the  document 
through  TRADES  when  a  DTIC  source  is  indicated, 
or  offline  when  another  source  is  indicated.  When 
the  hard  copy  document  is  obtained,  the  user  will 
review  the  document  and  extract  relevant  RAM  data. 

If  deemed  appropriate,  the  user  (designated  pro¬ 
ponent  only)  may  also  enter  selected  document  data 
into  the  Quick  Response  module  which  would  then 
make  this  information  available  on  a  recurring 
basis  to  other  TRADES  system  users. 

The  Source  Identification  Module  may  also  yield 
intelligence  that  data  is  available  in  the  Quick 
Response  module  as  well  as  external  automated 
systems,  such  as  COMRAM.  When  information  is 
available  in  the  Quick  Response  Module,  this  may 
be  provided  either  interactively  on  the  terminal 
or  off-line  printer,  or  may  be  requested  and 
mailed  to  the  user  if  terminal  capabilities  do  not 
exist.  Figure  5-4  indicates  the  flow  of  information 
from  a  quick  response  inquiry. 

Data  from  external  automated  sources  may  be  received 
either  in  raw  or  reduced  fashion.  Depending 
on  the  desires  of  the  RAM  engineer,  this  data  may 
be  further  manipulated  through  "what  if"  exercises 
on  the  TRADES  computer,  and  data  further  interpreted 
by  the  Statistical/Analytical  Module.  This  procedure 
is  illustrated  in  Figures  5-5  and  5-6. 

User  Update  Responsibilities 

Values  derived  through  manipulation  of  data,  or 
received  from  sources  such  as  tests,  may  be  stored 
in  the  Quick  Response  Module  by  the  proponent.  This 
data,  with  identifying/modifying  characteristics, 
will  then  be  available  for  comparative  information 
to  other  users  of  TRADES.  These  files  will  be 
updated  on  a  regular  as  well  as  "as  required" 
basis. 

Regular  update  routines  will  be  initiated  by  the 
TRADES  Management  Branch  based  on  the  management 
function  inherent  with  that  responsibility. 
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Figure  5-5.  Statistical/Analytical 
Module 
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FREQUENCY  OF  DATA  REQUIREMENTS 


Based  on  the  investigation  performed  during  the 
SRD  phase  of  the  TRADES  concept  study,  estimates 
for  the  frequency  of  RAM  data  inquiries  from  the 
TRADES  system  were  determined.  Table  5-1  is 
provided  with  appropriate  explanation: 


TABLE  5-1.  FREQUENCY  OF  DATA  REQUIREMENTS 


*  See  SRD  for  underlying  assumpt^ons/Frequency  of  TRADOC  RAM  Data 
Requirements. 

**  Not  assessed 

The  calculation  indicates  an  average  of  19,500  TRADOC 
requirements  per  year,  exclusive  of  other  DA  activi¬ 
ties  who  are  expected  to  be  frequent  users  of  TRADES. 
This  averages  375  inquiries  per  week  or  75  per  work 
day.  If  the  estimated  use  from  activities  outside  of 
TRADOC  is  as  high  as  anticipated,  the  average  work 
load  could  range  to  between  20,000  and  40,000  actions 
per  year;  or  between  80  and  160  per  day. 

Values  in  Table  5-1  may  be  high,  but  are  used  to  ade¬ 
quately  size  the  system.  The  value  of  160  requests 
per  day  are  estimated  to  be  an  outside  limit. 


The  nature  of  the  requests  are  in  support  of  the 
types  of  requirements  listed  below.  These  are 
arranged  in  descending  frequency  of  order  use. 

1.  Evaluation  of  established  RAM  requirements. 

2.  Test  Evaluation. • 

3.  Development  of  RAM  requirements  for  new  system. 

4.  Test  planning/design. 

5.  COEA. 

6.  Analysis  of  fielded  equipment. 

7.  Maintenance  manpower  and  logistics  analysis 
( MMLA ) . 

8.  Evaluation  of  contractor  RAM  forecasts. 

9.  Simulations. 

10.  Ad  hoc  requirements. 

11.  Special  studies. 

12.  Technology,  state-of-the-art  projections. 

13.  Special  task  force  efforts. 

14.  Other. 

VOLUME  OF  DATA  REQUIREMENTS 

The  volume  of  data  requirements  is  estimated  for 
the  system  based  on  the  chart  shown  in  Table  5-2. 
These  data  are  representative  of  the  volume  of 
data  flow  based  on  anticipated  actions  by  proponents 
and  the  relative  size  of  the  data  base  files. 
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TABLE  5-2.  ESTIMATED  FREQUENCY  AND  VOLUME 
OF  TRADES  REPORTS 


REPORT 

FREQUENCY 
PER  DAY 

AVERAGE 

VOLUME 

(CHARACTERS) 

TOTAL 

VOLUME 

(CHARACTERS) 

Source  Data  Inquiries 

40 

6,000 

240,000 

Data  Extraction 
and  Analysis 

2 

58,000 

116,000 

Quick  Response  Inquiries 

35 

1 ,200 

42,000 

Quick  Response  Updates 

2 

1 ,200 

2,400 

Mgmt.  Update  Report 

1 

30,000 

30,000 

TOTAL 

430,400 

♦Rounded 

Values  in  Table  5-2  were  determined  based  on 
estimates  derived  from  the  expected  data  element 
sizes.  The  volume  of  use  was  derived  in  the  SRD, 
Page  3-34,  and  estimated  utilization  of  the 
capabilities  of  TRADES  by  TRADOC  RAM  engineers. 
Source  identification  data  and  quick  response 
inquiries  were  based  on  an  average  estimate  of  75 
uses  per  day.  This  totals  approximately  19,500 
requests  per  year,  or  375  requests  per  week. 
Although  these  values  may  be  high,  they  are  used 
to  adequately  size  the  system. 


Data  Extraction  and  Analysis  reports  are  based  on 
the  typical  results  of  test  data,  estimating  a 
test  report  to  be  14  pages,  60  lines  per  page, 
with  70  characters  per  lire.  The  Quick  Response 
file  is  available  for  results  of  these  manipulations 
on  an  as  required  basis,  estimated  to  be  once  for 
each  analysis  performed. 

The  Management  Update  Report  represents  the  necessary 
management  actions  to  review  files  for  necessary 
update  and  deletion  of  entries  from  both  the  Quick 
Response  Module  and  the  Source  Identification 
Module . 
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TRADES  MANAGEMENT  BRANCH 

The  TRADES  Management  Branch  should  be  a  responsibility 
of  the  U.S.  Army  Logistics  Center.  This  recommenda¬ 
tion  tracks  with  the  responsibility  for  the  LOGC 
to  be  the  central  agency  within  TRADOC  for  the 
guidance  and  review  of  RAM  related  functions. 

TRADES  functions  will  reside  in  two  directorates 
with  the  LOGC.  The  responsibilities  are  divided 
into  a  functional  element  and  a  data  processing 
support  element. 

The  functional  element  will  be  called  the  TRADES 
Management  Branch.  It  would  be  assigned  to  the 
RAM/  ILS  Division  of  the  Materiel  Systems  Directorate. 

Functions  and  responsibility  of  the  TRADES  Management 
Branch  were  introduced  in  the  ACO  (Page  2-18),  and 
are  further  amplified  here. 


TRADES  System  Management 


This  entails  the  responsibilities  which  relate  to 
the  establishment  of  the  strategy  for  directing 
the  system,  relative  emphasis,  and  development  of 
"where  TRADES  must  go"  to  be  of  maximum  service. 

Such  management  necessarily  includes  assessment  of 
cost/benefit  of  all  aspects  of  operations.  All 
management  responsibilities  for  a  major  data 
system  will  reside  with  this  branch.  Responsi¬ 
bilities  include  planning,  forecasting  resource 
requirements,  insuring  that  +  he  performance  require¬ 
ments  of  TRADES  are  being  achieved,  and  taking 
necessary  adjustment  actions  to  ensure  that  TRADES 
is  properly  managed.  Priorities  and  workloading 
must  be  given  to  the  data  processing  element. 

TRADES  continuing  development  and  enhancement 
efforts  are  also  a  responsibility  of  this  branch. 


This  function  relates  to  being  able  to  make  the 
maximum  legitimate  and  proper  inference  from  the 
data  and  to  develop  the  techniques  necessary  for 
this  purpose.  Further  responsibilities  are  to 
assist  the  respective  users  and  effect  a  proper 
standardization  among  the  methods  of  the  prospective 
users.  '  This  activity  will  address  RAM  analysis 
techniques  and  the  application  of  these  techniques. 
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Source  and  User  Service 


This  area  concerns  source  and  user  services,  to 
ensure  the  linkage  of  desired  information  with  the 
appropriate  source.  This  function  will  entail  the 
identification  of  new  sources  of  RAM  information, 
search  in  response  to  inquiries  not  satisfied  by 
TRADES,  and  the  necessary  support  when  results  are 
unsatisfactory  from  the  automated  system. 

DATA  PROCESSING  ELEMENT 

The  data  processing  element  will  function  as  part 
of  the  Planning  Factors  Management  Division  of  the 
Operations  Analysis  Directorate,  U.S.  Army  Logistics 
Center.  The  responsibilities  inherent  within  this 
d:!  ectorate,  for  TRADES  support,  are  primarily  for 
programming  changes  and  developing  procedures  for 
meeting  special  requirements  generated  by  users  or 
the  TRADES  Management  Branch.  This  element  also 
ensures  that  the  automated  interfaces  with  major 
data  bases  are  kept  current  and  arranges  automated 
interface  with  other  systems  as  required.  It 
is  also  responsible  for  ensuring  that  the  TRADES 
system  is  operating  on  a  daily  basis. 

Another  function  identified  in  the  data  processing 
area  must  be  considered.  These  functions  include 
computer  management ,  computer  purchasing,  services, 
maintenance  contracts,  disposal  of  unneeded  equip¬ 
ment,  utilization  reporting,  economic  analysis, 
and  ADP  budgeting.  These  functions  are  performed 
currently  by  the  OAD  of  the  LOGC. 

EXTERNAL  SOURCES 

These  acti  'ities  are  fully  described  in  Chapter  IV 
of  the  SRD.  These  sources  are  an  essential  ingredient 
of  TRADES  and  run  the  gamut  from  automated  data 
systems  to  hard  copy  test  results.  Automated 
systems  provide  information  on  interactive  or 
batch  method  to  TRADES,  as  required.  It  is  not 
anticipated  that  TRADES  will  be  automatically 
updated  by  any  of  these  systems  on  a  recurring 
basis,  but  will  function  by  extracting  data  from 
sources  on  an  "as  required"  basis.  Results  of 
these  data  extractions  and  manipulations  will 
subsequently  be  storec  in  the  TRADES  computer  and 
readily  available  for  further  use. 
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VOLUME  OF  DATA  REQUIREMENTS-USERS 


The  volume  of  data  requirements  is  difficult  to 
assess,  since  the  very  existence  of  TRADES  will 
increase  the  amount,  as  well  as  the  validity  of 
the  flow  of  RAM  information.  The  chart  shown  in 
Table  5-3  reflects  the  current  number  of  develop¬ 
mental  systems  which  are  the  responsibility  of 
TRADOC.  These  activities  are  related  to  the 
TRADOC  schools  with  an  average  system  complexity 
factor  for  the  typical  system  developed  in  that 
commodity  area.  This  complexity  factor  was  sub¬ 
jectively  derived  and  represents  an  estimate  of 
system  complexity  and  subsystems/components 
related  to  the  typical  item.  (See  Table  5-4). 
This  computation  provides  a  yield  of  the  relative 
flow  of  data  to  and  from  each  school,  as  follows: 


ACTIVITY 

Ordnance  School 

51648 

Transportation  Center  &  School 

30128 

Missile  &  Munitions  Center  8s  School 

34432 

Quartermaster  School 

4304 

Combined  Arms  Center 

4304 

Field  Artillery  Center  8s  School 

43040 

Infantry  Center  8s  School 

30128 

Armor  Center  8s  School 

17216 

Air  Defense  School 

25824 

Signal  School 

60256 

Engineer  Center  8s  School 

38736 

Intelligence  Center  8s  School 

21520 

Chemical  Center  8s  School 

8608 

Aviation  Center  8s  School 

60256 

Military  Police  School 

Min . 

Institute  of  Military  Assistance 

Min . 

Logistics  Center* 

Min . 

Total 

430400 

This  data  is  representative  of  the  automated 
traffic  flow  which  is  expected  in  the  TRADES 
system  and  is  based  or.  a  percentage  of  the 
activity  flow  portrayed  in  Table  5-1. 

*  Includes  only  those  items  for  which  the  LOGO  is  the 
proponent . 


TABLE  5-3.  COMBAT  DEVELOPMENT  SYSTEMS  MATERIEL 
LOGISTIC  RESPONSIBILITY 


TRADOC 

ACTIVITY 

LOGISTICS  Rl 

ESPONSI BI LITY 

SYSTEM 

PROPONENCY 

PRIMARY 

SECONDARY 

NO.  OF 
SYSTEMS 
TOTAL 

Ordnance  School 

16 

125 

27 

168 

Transp.  School 

82 

81 

12 

175 

Missile  &  Munitior 

is  9 

96 

105 

Quartermaster 

33 

68 

1 

102 

Combat  Arms  Center 

9 

9 

A.  Nuclear  Agency 

1 

1 

Field  Artillery 

75 

7 

82 

Infantry  School 

71 

1 

72 

Armor  School 

34 

34 

Air  Defense 

29 

2 

31 

Signal  School 

297 

15 

419 

Engineer  School 

101 

4 

215 

Intel 1 igence 

62 

9 

71 

Chemical 

55 

41 

3 

99 

Aviation 

2 

6 

113 

Military  Police 

12 

1 

13 

IMA  , 

16 

1 

17 

LOG  Center 

12 

12 

Alaska 

1 

1 

ASD-TRADOC 

1 

1 

ATSC 

1 

1 

Admin.  Center 

_ 1 

1 

1 

TOTALS 


842 


829 


71 


1742 


TABLE  5-4.  WORKLOAD  COMPUTATION 


TRADOC 

ACTIVITY 

WEIGHTED 

SYSTEMS 

WORKLOAD* 

COMPLEXITY 

FACTOR  a/ 

_  - 

COMPLEXITY 
TOTALS  b/ 

PERCENT 

WORKLOAD^/ 

OCS 

184 

12 

2208 

12 

TSCH 

257 

5 

1258 

7 

MMCS 

114 

14 

1596 

8 

QMS 

135 

2 

274 

1 

CAL 

18 

14 

252 

1 

ANA 

- 

- 

- 

- 

FAS 

157 

12 

1884 

10 

INS 

143 

9 

1287 

7 

ARMC 

68 

12 

816 

4 

ADS 

60 

19 

1140 

6 

SIGS 

526 

5 

2630 

14 

ENS 

325 

5 

1625 

9 

I  NTS 

133 

15(7) 

931 

5 

CHEMS 

154 

2 

308 

2 

AVNS 

218 

12 

2616 

14 

MPS 

25 

2 

50 

- 

IMA 

33 

2 

66 

- 

LOGC 

24 

2 

48 

- 

AKA 

- 

- 

- 

- 

ASD 

- 

- 

- 

- 

ATSC 

- 

- 

- 

- 

SSC 

- 

- 

- 

- 

TOTAL 

18989  d/ 

100 

♦Relative  system  workload  based  on  unit  weight  for  logistics  responsible  systems 
and  2  x  factor  for  proponent  systems. 
a/Subject  complexity  factors  assumed  for  this  study 
b/Product  of  Columns  2  and  3. 

c/Percent  distribution  of  complexity  totals  -Col.  4  (assumed  relative  workload). 
3/  Unique  staffing  through  QAC  process  reduces  estimated  RAM  workload. 


Mainframe  Computer 

Mini-Computer 

Line  Printers 

Card  Reader 

Tape  Drives 

Disk  Drives 

Micro-Computers  or 
Interactive  Terminal 

Security  Equipment 

Dedicated  Lines 

Multiplexers 

Modems 

Plotter 

Graphic  Terminals 
Automatic  Dialer 


TABLE  6-2.  HARDWARE  OVERVIEW 


HARDWARE 

CONCEPT  CHARACTERISTICS 

Mainframe 

Time  share  with  DPFO  large  mainframe  computer  with 
batch  and  interactive  capability  through  terminals 

Minicomputer 

Utilizes  a  LOGC  minicomputer  with  multiple  terminals 
capability  to  handle  processing  and  report  dissemin¬ 
ation.  Estimated  need  of  2-4  MB  of  local  memory 

Line  Printed 

Use  high  speed  line  (600  LPM)  printer  located  at 

LOGC  Computing  Center  and  with  each  remote 
terminal 

Card  Reader 

Use  50-200  CPM  Card  Reader  located  at  LOGC  Computing 
Center 

Tape  Drives 

Use  9-Track  tape  drives  located  at  LOGC  Computing 

Center  and  DPFO 

Disk  Drives 

Use  DPFOs  and  LOGC  disk  drives  and  disks  for  support 
of  TRADES.  Minimum  of  90  MB  storage  capability 
initially 

Microcomputers  or 
Interactive  Terminals 

Use  microcomputer  and  any  interactive  terminal  with 
communications  equipment  for  interactive  operations 

Security  Equipment 

Use  in-place  KG  device  for  1/0  transactions 

Communications 

Equipment 

Use  a  4800  Baud  dedicated  line  from  the  TRADES 

Office  via  the  PFDB-TRADE  minicomputer  office  to 

DPFO  and  other  computer  ports  for  interactive 
processing 

Multiplexers 

Asynchronous,  minimum  of  eight  (8)  communications 
lines 

Modems 

Modems  and  cables  as  necessary  for  multiplexer  re¬ 
quirement.  Also  needed  with  each  terminal /mini¬ 
computer 

Graphics  Terminals 

Graphics  terminals  and  plotting  equipment,  prefer¬ 
ably  color  systems,  for  requirements  and  performance 
charting 

Located  at  Fort  Leavenworth  DPFO  are  time-scaring 
computer  mainframes  with  extensive  mass  storage. 

At  present,  these  consist  of  two  UNIVAC  1100/32 
systems;  one  for  classified  processing  and  one  for 
unclassified  processing.  These  systems  are 
available  on  a  time-share  basis  with  batch  or 
interactive  capability  through  terminals.  Both 
systems  are  currently  operating  and  have  sufficient 
capacity  to  handle  TRADES  on  a  back-up  basis. 

One  mini-computer  will  be  located  at  Fort  Lee,  VA. 
This  mini-computer  will  be  time-shared  with  the 
PFDB  system.  It  will  utilize  multiple  terminals 
to  handle  report  dissemination  on  an  interactive 
basis.  The  computer  will  have  its  own  DBMS,  batch 
terminal,  public  and  private  disk  packs,  a  nine- 
track  tape  drive,  and  communications  equipment,  so 
that  it  can  operate  independently. 

It  should  be  noted  that  the  actual  equipment  spe¬ 
cifications  for  the  PFDB  will  be  developed  in  the 
1982-1983  time  frame,  during  its  design/development 
phase.  Similarly,  the  detailed  hardware  specifica¬ 
tion  for  TRADES  will  be  developed  in  the  design/ 
development  phase  of  TRADES. 

The  primary  purpose  of  the  automated  data  system 
(ADS)  for  TRADES  is  to  execute  the  functions  ex¬ 
plained  in  the  other  portions  of  the  STP.  Essen¬ 
tially,  the  hardware  must  satisfy  both  the  EEI 
requirements  and  the  EEA  specifications,  using  the 
internal  and  external  operating  procedures  speci¬ 
fied  therein. 

The  following  discussion  of  hardware  requirements 
is  provided  with  the  intention  of  specifying  to  a 
greater  degree,  the  required  characteristics  and 
capabilities  of  the  hardware  envisioned  in  the 
TRADES  concept.  It  must  be  recognized  that  at  this 
stage,  estimates  of  requirements  are  partly  based 
on  assumptions  of  integration  with  hardware  which 
will  support  the  PFDB. 


Descriptive  requirements  are  in  terms  of  proces¬ 
sors,  storage  media,  input  and  output  devices,  and 
communications  equipment. 

Primary  hardware  requirements  are  addressed  by  lo¬ 
cation;  that  is,  PFMD ,  LOGC  Computing  Center,  the 
TRADES  Management  Branch,  and  the  typical  users. 

DPFO  requirements  are  not  addressed  in  these  terms, 
since  the  capabilities  and  capacities  to  meet 
TRADES  requirements  are  essentially  available,  bar¬ 
ring  unforeseen  growth  of  TRADES  or  other  users  of 
the  DPFO. 

EQUIPMENT  CONSIDERATIONS 

The  equipment  required  for  TRADES  should  be  standard, 
commercially  available  data  processing  hardware. 
Equipment  at  the  user  locations  should  be  capable 
of  operation  by  non-ADP  personnel.  Because  TRADES 
.  was  designed  to  avoid  special  hardware  requirements, 

delays  for  development  of  computer  associated  equip¬ 
ment  to  handle  TRADES  are  not  foreseen. 

The  TRADES  system  will  operate  using  central  proces¬ 
sors,  disk  and  tape  storage  media,  remote  output  and 
input  devices,  and  will  utilize  appropriate  communi¬ 
cation  equipment  for  a  partially  distributed  data 
system. 

Power  Requirement 

Commercial  power  sources  will  be  used  to  provide 
operating  electricity.  Since  TRADES  will  operate  in 
a  CONUS-base  environment,  not  under  combat  conditions, 
local  generating  power  is  not  required.  Back-up 
emergency  battery  power  is  required,  however,  to  pre¬ 
vent  loss  of  data  and  equipment  malfunction  due  to 
unexpected  power  interruptions.  Consideration  will 
be  given  to  equipment  that  is  energy  conservative. 

Climatic  Considerations 

No  unusual  requirements  are  noted,  due  to  the  opera¬ 
ting  environment.  The  equipment,  in  general,  must 
perform  in  a  normal  office  building  environment. 


Transportability 

The  terminals  (CRT  and  keyboard),  modem,  and  line 
printers  at  user  locations  should  be  lightweight, 
and  be  able  to  be  carried  by  two  personnel,  to 
facilitate  movement  from  one  office  to  another. 
These  devices  shall  not  require  extensive  rewiring 
of  buildings,  and  should  be  accommodated  by  a  120 
vclt  power  source  and  Autovon/Federal  Telephone 
Service  (FTS)  telephone. 

Nuclear,  Biological, 

Chemical  (NBC)  Survivability 

No  special  standards  are  specified  for  this  system 
since  it  is  not  anticipated  to  operate  in  an  NBC 
environment,  nor  is  it  deemed  essential  during 
periods  of  attack  on  CONUS  facilities. 

Perronal  Safety 

The  devices  should  be  constructed  and  installed  in 
such  a  manner  as  to  preclude  electrical  and  mechani 
cal  hazard  to  the  operator,  thus  providing  maximum 
safety. 


PROCESSORS 


Central  processing  units  are  required  at  DPFO  and 
the  LOGC,  Planning  Factors  Management  Division. 

The  central  processor  at  the  LOGC  for  PFMD  is 
assumed  to  have  the  following  capabilities,  which 
will  meet  the  TRADES  requirements: 

1.  Sufficient  processing  capacity  to  process  both 
Planning  Factors  inquiries  and  job-runs,  as 
well  as  TRADES,  on  an  interactive  and  time-share 
basis. 

2.  The  computer  must  be  capable  of  sustained  opera¬ 
tion  for  a  minimum  of  eleven  hours  a  day. 

3.  The  Control  Processing  Unit  (CPU)  must  be  able 
to  accept  input  transactions  from  a  minimum  of 
40  remote  sites  (maximum  of  eight  concurrently), 
and  an  average  of  75  requests  per  day  for  TRADES 

4.  The  CPU  must  be  able  to  manipulate  data  on  an 
interactive/rapid  response  basis,  and  perform 
arithmetic-logic  functions,  as  programmed. 
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5.  The  CPU  must  also  have  a  floating  point  capability 
for  higher  mathematical  functions.  Additionally, 

a  capability  must  exist  to  accept  a  commercial/ 
governmental  statistical  software  packages  commonly 
available  (typically,  Fortran  programs). 

6.  The  CPU  should  have  a  minimum  of  2-4  megabytes  (MB) 
local  memory  for  logical  operations. 

7.  Likely  system  characteristics  include  a  32-bit 
virtual  memory  system,  16  32-bit  general  purpose 
registers,  32  interrupt  priority  levels,  12K  bytes 
of- writable  diagnostic  storage,  8K  bytes  write- 
through  memory  cache,  console  subsystem,  intelli¬ 
gent  micro-computer,  main  memory  of  512K  Bytes  plus 
1.5  MB  add-on,  synchronous  back  plane  interconnect, 
176  MB  disk  drive  with  controller,  magnetic  tape 
800/1600  BPI  45  IPS-9  track,  hard  copy  terminals, 
8-channel  communications  multiplexer,  hardware 
bootstrap  load,  battery  back-up  time-of-day  clock 
with  bootstrap  load,  standard  operating  system  and 
text  editor,  graphic  capability,  and  associated 
plotting  equipment.  It  is  stressed  that  this 
capability  is  shared  with  the  PFDB. 

STORAGE  AREA 

Computer  on-line  disk  storage  random  access  capabili¬ 
ties  are  required  for  all  modules,  except  for  the 
Management  Module  corporate  history  files,  which  may 
be  placed  on  magnetic  tape  (or  equivalent)  for  in¬ 
definite  storage.  The  TRADES  requirement  for  80  mega¬ 
bytes  must  be  accommodated  with  anticipated  disk 
storage  devices  for  PFDB.  If  necessary  for  later  ex¬ 
pansion  (which  could  conceivably  be  of  the  order  of 
900  megabytes),  dedicated  drives  and  disks  may  be 
needed.  Although  the  terms  "disks  and  tapes"  are 
used  for  explanatory  purposes,  consideration  of 
greatly  improved  state-of-the-art  devices  will  en¬ 
hance  the  storage  capabilities  of  the  computers,  and 
should  be  considered  at  that  time. 

It  is  anticipated  that  the  selected  computer  system 
will  have  a  virtual  storage  capability.  This  capa¬ 
bility  will  enable  programming  to  be  performed  with¬ 
out  concern  as  to  whether  the  program  fits  within 
the  space  provided  for  the  primary  storage.  It 
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also  uses  all  available  storage  space  when  executing 
jobs.  This  storage  gives  great  flexibility  for  sys¬ 
tems  such  as  TRADES,  which  will  be  time-sharing  with 
PFDB. 

INPUT  DEVICES 

The  central  computer  must  have  the  ability  to  receive 
input  from  a  variety  of  input  devices.  The  prime 
methods  of  inputting  data  include  punched  cards, 
magnetic  disk  (computer-to-computer) ,  magnetic  tape, 
interactive  remote  terminals,  and  remote  mi cro- computer . 

Punched  Card  Reader 

A  punched  card  reader  is  assumed  to  be  part  of  the 
PFMD.  No  remote  user  wilt  require  this  capability. 

This  reader  should  have  a  minimum  capability  of 
reading  data  into  the  computer  at  a  speed  of  300 
cards  per  minute. 

Disk  Packs 


Disk  packs  are  read  by  the  computer.  The  normal 
peak  transfer  rate  and  access  time  used  in  commer¬ 
cial  devices  is  adequate  for  the  TRADES  system. 

(A  representative  manufacturer  today  uses  806  KB 
peak  transfer  rate  and  38.3  ms  average  access  time.) 

Also,  computer-to-computer  transfer  of  data  capabil¬ 
ity  is  required  (to  include  both  hard  and  floppy  disks) 
which  could  be  disk-to-disk,  disk-to-tape ,  tape-to- 
tape,  or  tape-to-disk. 

Magnetic  Tape 

Magnetic  tape  is  machine-readable,  and  is  convenient 
for  storing  and  mailing  large  amounts  of  data.  An 
average  tape  of  2400  feet  has  the  ability  to  store 
14  megabytes  of  characters,  and  is  relatively  inexpen¬ 
sive.  Therefore,  the  frequent  use  of  tape  is  anti¬ 
cipated  when  obtaining  data  for  analysis. 

The  PFDB  system  will  have  a  magnetic  tape  drive, 
which  has  the  capability  referred  to  in  the  proces¬ 
sor  paragraph.  It  is  anticipated  that  another  tape 
drive  will  not  be.  required  for  the  exclusive  use  of 
TRADES.  However,  if  response  to  the  user  is  slow, 
TRADES  should  be  prepared  to  augment  with  an  addi¬ 
tional  drive. 
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Micro-Computer 


Micro-computers  will  be  used  in  lieu  of  interactive 
remote  terminals  by  the  PFMD,  the  TRADES  Management 
Branch,  and  selected  TRADOC  primary  users.  The  micro¬ 
computers  need  to  be  equipped  with  modems,  and  the 
necessary  communications  equipment  to  enable  the 
micro-computer  to  be  used  for  direct  input  to  the 
TRADES  central  processor.  Capacities  needed  are 
dependent  on  the  workload  at  those  locations.  The 
TRS-SO  in  the  RAM/ILS  Division  and  the  anticipated 
micro- computer  at  PFMD  are  deemed  adequate  for 
those  activities. 

Interactive  Remote  Terminal 

This  terminal  will  be  located  with  the  primary 
school/center  users.  These  devices,  consisting  of 
a  keyboard  and  CRT  (and  line  printer)  are  used  to 
access  the  PFMD  and  DPFO  central  computers.  They 
cause  the  data  to  be  manipulated  and  also  enable  the 
entry  of  selected  data  into  the  computer.  Speed  re¬ 
quirements  for  the  terminal  are  4,800  bits  per  sec¬ 
ond,  considering  that  most  transmissions  will  be 
performed  over  commercial  lines;  this  transmission 
rate  is  subject  to  review  during  the  design/develop¬ 
ment  phase. 

OUTPUT  DEVICES 

Most  of  the  input  devices  previously  mentioned  also 
serve  as  output  devices.  These  include  card  punches, 
disk  packs,  magnetic  tape,  micro-computers,  interac¬ 
tive  remote  terminals,  and  line  printers. 


Card  Punch 

Card  punch  machines  may  be  needed,  and  are  available 
in  the  LOGC  Computing  Centers.  Normal  commercial 
standards  apply. 

Disk  Packs 

Disk  packs  previously  mentioned  may  be  used  as  an 
output  device.  This  use  will  be  primarily  for  disk- 
to-disk  operations.  Capabilities  previously  descrit  'd 
apply. 
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Magnetic  Tape 

Magnetic  tape  is  used  as  a  common  vehicle  for  trans¬ 
mitting  data  to  and  from  computing  facilities.  Pre¬ 
viously  indicated  standards  apply. 

Micro-Computers 

Micro-computers  may  be  used  as  an  output  device. 

The  micro-computer  may  use  internal  storage  devices, 
such  as  internal  memory  or  floppy  disk  devices. 

Many  micro-computers  L«.ve  a  relatively  limited  stor¬ 
age  capability,  and  care  should  be  taken  to  ensure 
that  these  limits  are  not  exceeded. 

Interactive  Remote  Terminals 

These  terminals  serve  as  the  most  common  output  de¬ 
vice  at  user  locations.  The  device  will  typically 
use  a  CRT  or  other  display  to  provide  information  to 
the  operator.  Upon  command,  hard  copy  reports  are 
provided  to  the  user  via  an  attached  printer. 

Line  Printers 

This  device  v’ill  provide  printed  output  at  remote 
locations,  TRADES  Management  Branch,  and  PFMD .  The 
print  capability  should  be  132  characters  per  page, 
multiple  (4)  copies  required,  if  necessary,  for 
each  report . 

Graphics  Terminal 

Already  anticipated  to  be  part  of  the  PFDB  system, 
the  graphics  terminal  is  required  for  plotting  of 
graphs,  trend  lines,  mathematical  functions,  etc. 
This  capability  is  required  at  the  PFMD,  and  can 
serve  ?11  users.  Plotting  can  also  be  done  using 
the  1 ine  printer  at  remote  locations. 

COMMUNICATIONS 

Communications  equipment  requirements  are  needed 
to  tie  the  system  together.  At  the  central  loca¬ 
tion,  a:i  additional  8-channel  communications 
asynchronous  multiplexer  (up  to  9600  Baud) 
will  be  required,  along  with  necessary  modems  to 
accomplish  this  task.  The  primary  function  of  this 
equipment  is  to  enable  multiple  use  of  the  computer 


by  several  remote  inquiries  occurring  simultaneously. 
It  is  estimated  that  no  more  than  eight  remote  in¬ 
quiries  will  occur  at  any  one  time.  The  computer 
should  be  expandable  to  a  maximum  of  48  lines,  if 
needed,  to  accommodate  growth  of  both  TRADES  and 
PFDB.  Integration  of  TRADES  with  tactical  communi¬ 
cations  network  is  not  required. 

Mode  s  ( and  cables)  will  also  be  needed  with  each 
remow  *  -rminal  and  micro-computer,  and  for  the 
asynchronous  multiplexers.  This  function  provides 
for  connection  of  asynchronous  interfaces  or  termi¬ 
nals  having  Electronics  Industry  Association  inter¬ 
faces. 

Communications  Lines 

A  dedicated  line  is  required  between  the  TRADES  Man¬ 
agement  Branch  terminal  and  the  PFMD  computer,  and 
a  dedicated  multiplexed  line  between  the  LOGC  com¬ 
puting  Center  and  DPFO.  All  other  communications 
lines  can  be  served  using  Autovon/FTS,  or  standard 
commercial  circuits. 

SECURITY 

Security  equipment  requirements  will  be  accommodated 
by  secure  facilities  presently  located  at  TRADOC  in¬ 
stallations  (KG-13  devices  are  in  use  for  this  pur¬ 
pose).  The  current  amount  of  classified  is  rela¬ 
tively  low;  therefore,  this  approach  is  sufficient 
for  the  foreseeable  future.  TRADES  terminal  will  not 
be  required  to  handle  classified  materiel. 


SUMMARY 


The  hardware  selected  for  TRADES  satisfies  the 
Essentia.1  Elements  of  Analysis  (EEA)  required  by 
the  SRD.  The  availability  of  terminals  to  all  RAM 
users  provides  ultimate  accessibility  to  the 
TRADOC  community.  Flexibility  is  maximized  with 
the  provision  of  both  interactive  and  batch  processing 
capability.  The  large  scale  computers  and  communica¬ 
tions  equipment  selected  permit  maximum  integration 
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of  TRADES  with  other  systems.  Growth  potential  is 
high  due  to  the  back-up  capability  of  storage  and 
CPU  at  the  DPFO.  Resource  requirements  are  not 
significantly  different  than  other  systems  considered, 
and  maximize  utilization  of  sunk  costs  of  hardware, 
facilities,  and  personnel  in  being  or  programmed  for 
acquisition  by  1985.  Implementation  Time  is  reduced 
by  this  approach,  since  it  is  linked  to  the  utiliza¬ 
tion  of  equipment  presently  available  or  programmed 
for  acquisition.  Security  of  data  base  is  provided 
for  by  the  use  of  secure  lines  and  encipherment 
(as  required)  and  scrambling  techniques  currently 
available . 


CHAPTER  VII 


SOFTWARE  REQUIREMENTS 


GENERAL 


The  ensuing  section  will  address  the  software 
requirements  of  TRADES  in  tei’ms  of  the  five 
functional  modules  which  constitute  the  total 
system.  These  modules  whose  internal  operating 
characteristics  are  described  in  detail  in  Chapter 
IV  are  the: 

1.  Source  Identification  Module, 

2.  Quick  Response  Module 

3.  Interface  Module 

4.  Statistical/Analytical  Module,  and 

5.  Management  Module. 

The  general  software  structural  approach,  which 
has  been  applied  to  the  design  of  each  of  the 
modules,  is  shown  in  Figure  7-1. 

The  following  describes  the  software  and  its 
functions.  Command  or  data  inputs  by  users  or 
sources  will  be  verified  in  a  preprocessing  func¬ 
tion.  Any  errors  detailed  will  be  reported  back 
to  the  user/source  for  corrective  actions.  These 
errors  will  be  reported  either  in  hard  copy  print¬ 
outs  or  visual  display  media.  Verified  commands 
will  then  be  executed  and  data  stored  or  manipulated 
through  use  of  a  DBMS  or  analysis  routines. 

Several  DBMSs  are  available  cn  the  commercial 
market  that  are  sufficient  for  the  TRADES  system. 
These  are  systems  similar  to  System  2000,  DMS, 

(both  available  at  DPFO),  TOTAL,  IMS  and  a  host  of 
others.  Since  System  2000  is  already  available  at 
DPFO,  it  is  recommended  for  implementation  with 
TRADES.  With  respect  to  the  DBMS  for  the  VAX 
11/780  at  PFMD,  it  is  recommended  that  a  more 
recently  developed  "Relational  DBMS"  be  implemented. 
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Examples  of  "Relational  DBMS"  are  INGRES  (Relational 
Technology,  Inc.),  and  ORACLE  (Relational  Software, 
Inc).  The  advantages  of  these  relational  systems 
are  that  they  provide  high  level  of  query  language 
capability,  easier  use,  and  greater  flexibility  in 
modification  of  data  definitions. 

Finally,  data  retrieved  from  the  data  base  or 
analytical  manipulation  will  be  presented  to  the 
user  as  structured  output  from  a  report  generator. 
Interface  processing  will  also  be  provided  where 
required.  Both  the  report  generation  and  interface 
capabilities  will  be  contained  in  the  Post  Processor. 

User  Prompting 

User  prompting  is  a  technique  which  allows  the 
computer  to  become  user  friendly.  It  involves  an 
interactive  conversation  with  the  computer  such 
that  the  user  will  b  prompted  or  guided  to 
respond  to  a  logical  and  most  useful  response. 

The  two  methods  of  prompting  most  frequently  used 
are:  (1)  menu  selection,  where  a  list  of  items 

are  presented  ^nd  the  user  is  asked  to  select  one; 
and  (2)  a  single  question  v/ith  logical  choice 
displayed  in  a  manner  which  allows  the  user  to 
select  it  by  a  single  key  stroke  or  return  function. 

EXAMPLE : 

Computer:  Select  a  sta^istical/analytical 

package  from  the  following  list: 


1. 

Multiple 

regression 

2. 

Multiple 

Stepwise  Regression 

3. 

Chi-Square  Test 

4. 

Student  t 

-Test 

Number  Picked  by  User?  3 


Language  Requirement 


The  language  used  to  develop  the  TRADES  system 
should  be  selected  on  the  basis  of  it  being  able 
to  run,  as  a  minimum,  on  both  the  VAX  11/780 
located  at  PFMD  and  the  UNIVAC  1100  located  at 
DPFO  to  avoid  cost  of  software  development  for  two 
or  more  systems.  Further,  the  language  should  be 
interoperable  with  the  DBMSs  located  on  these  DPFO 
and  PFMD  computers. 

Lastly,  most  serious  consideration  should  be  given 
to  using  the  same  computer  language  for  TRADES  as 
that  used  for  the  PFDB.  This  will  be  beneficial 
in  design,  development,  implementation  and  mainten¬ 
ance  of  TRADES  in  terms  cf  cost  and  effectiveness 
of  operations,  i.e.,  it  would  be  more  difficult  to 
develop  and  maintain  systems  having  different 
languages  at  a  single  facility. 

Selection  of  a  higher  order  structured  language 
should  also  be  considered  over  FORTRAN  or  COBOL  be¬ 
cause  of  its  advantages  in  post  implementation  sup¬ 
port  and  ease  of  maintenance. 

Source  Identification  Module 


Software  developed  for  this  module  will  provide 
the  TRADES  user  with  information  of  sources  of  RAM 
data  and  allow  query  by  a  taxonomy  including 
commodity,  end  item,  major  system/subsystem,  and 
selected  components  levels.  The  following  describes 
the  software  required  to  accomplish  this  function: 

1.  Preprocessor .  This  software  will  verify 
query  commands  to  the  data  base  management 
system.  Also,  the  software  will  prompt  the 
user  to  enable  more  efficient  query  of  data 
and  more  specific  reports. 

2.  Main  Processor.  The  software  for  the  main 
processing  of  source  identification  data  will 
be  that  of  a  DBMS.  Access  language  to  the 
DBMS  will  be  that  peculiar  to  the  system 
acquired  and  implemented. 

3.  Post  Processor.  Software  for  the  post  processo 
will  provide: 

(1)  Agency  and/or  activity  with  appropriate 
RAM  data  holdings. 
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(2)  Extent  of  holdings  (years  of  information, 
number  of  test  reports,  total  number  of 
records,  etc.) 

(3)  Form  of  data  (test  reports,  raw  field 
data,  reduced  data,  analysis  results, 
etc.)  at  activities. 

(4)  Environmental  conditions  (e.g.,  peacetime 
versus  combat,  geographical  area,  arctic 
versus  tropical,  desert  versus  cultivated 
areas,  etc.  ) 

(5)  Point  of  contact. 

(6)  If  automated  data  ba,se : 

a.  Accessibility  through  user  terminal. 

b.  Necessary  passwords,  machine  inter¬ 
face,  baud  rate,  etc. 

c.  Protocol  and  procedures  for  obtaining 
data. 

d.  Description  of  file  layouts  (essential 
elements  of  information  (EEIs)  in 
each  field  of  data). 

e.  Necessary  identification  and  definition 
of  terminology  to  provide  the  user 
with  information  relative  to  user 
requirements  which  may  be  matched 

by  the  data  base. 

This  software  shall  propose  reports  either  in 
fixed  format  of  summary  data  or  on  a  query-by¬ 
query  basis. 

Additional  software  is  required  to  trigger  the 
"automatic  dialer"  equipment  to  access  the  Defense 
RDT&E  On-Line  System  (DROLS)  automatically  through 
the  TRADES  system.  This  software  will  notify  user 
if  access  is  not  available  at  the  time  and  will 
allow  user  to  terminate  or  continue  query.  (See 
Appendix  C) 
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Quick  Response  Module 


This  module  provides  an  immediately  accessible  value 
for  each  applicable  EEI  (and  the  conditions  under 
which  it  was  derived)  for  the  system.  The  values 
represent  the  best  technical  estimate  for  the  EEIs 
based  on  all  available  data  for  the  system.  The 
values  contained  in  the  Quick  Response  Module  are 
updated  by  the  TRADOC  proponent  agency  upon  the 
availability  of  more  current/more  accurate  data  as 
the  system  progresses  through  the  life  cycle. 

The  following  describes  the  specific  software 
requirements  for  this  module : 

1.  Preprocessor.  Software  will  be  required  that 
will  allow  query  commands  to  be  verified  and 
user  prompting  to  allow  efficient  responses. 

2.  Main  Processor.  Similar  to  the  Source  Identi¬ 
fication  module,  the  software  for  the  Quick 
Response  Module  will  be  that  of  a  DBMS  and 
access  determined  by  the  particular  DBMS 
query  language.  The  DBMS  will  be  structured 

in  accordance  with  the  taxonomy  lrom  commodity 
through  selected  component  levels  with  associat¬ 
ed  "acceptable  values." 

3.  Post  Processor.  The  software  required  will 
be  a  report  writer  capable  of  producing 
either  fixed  formatted  summary  or  individual 
query-by-query  reports. 

Interface  Module 


This  module  will  contain  the  necessary  information 
to  communicate  with  the  diverse  computers  having 
RAM  data  bases  within  DA  (or  other  military  services). 
Access  to  the  Interface  Module  will  be  indicated 
by  the  Source  Identification  Module,  depending  on 
the  specific  user  requirements  and  source  identific¬ 
ation.  To  the  extent  feasible,  this  module  will 
contain  software  to  provide  the  user  with  a  basic 
vehicle  for  extracting,  analyzing,  and  formatting 
outputs  from  automated  data  sources. 

The  following  describes  the  software  requirements 
for  this  module: 


1. 


Preprocessor .  Software  will  be  required  that 
will  allow  query  commands  to  be  verified  and 
user  prompting  to  allow  efficient  responses. 


2.  Main  Processor.  Since  the  automated  data 

base  will  be  identified  by  the  Source  Identi¬ 
fication  Module  that  was  previously  queried, 
query  will  be  by  the  data  base  name  or  abbre¬ 
viation  (e.g.  COMRAM,  SAMS,  TMIS,  etc.).  The 
main  processor  software  requirement  will  be 
that  of  a  simple  sequential  file  with  detailed 
information  on  each  automated  data  base 
containing  the  appropriate  RAM  data. 

3*  Post  Processor.  The  report  generator  will 

simply  list  the  appropriate  data  base  name  or 
abbreviation  and  print  all  information  required 
for  access  and  usage. 

Where  an  identified  data  base  is  designed  for 
interactive  processing,  this  software  will  allow 
automatic  access  through  use  of  the  "automatic 
dial  up"  equipment.  Similar  to  access  to  the  DTIC 
system,  the  software  will  be  designed  to  notify 
the  user  of  queues  or  busy  ports  to  these  data 
bases  so  that  the  user  may  leave  job  in  queue  for 
future  processing. 

Statistical/Analytical  Module 

The  objeccive  of  the  Stat isticai/ Analytical  Module 
is  to  facilitate  RAM  analysis,  perform  tests  of 
hypotheses,  determine  whether  the  effect  is  due  to 
chance,  whether  there  are  trends,  and  assess  the 
stability  of  observations. 

The  software  requirements  to  accomplish  this 
objective  are  detailed  as  follows: • 

1.  Preprocessor .  Software  in  the  preprocessor 
will  provide  for  selection  by  the  user  of 
various  statistical/analytical  packages 
contained  in  this  module.  These  will  be 
presented  by  name  of  the  particular  statistical/ 
analytical  function  along  with  a  short  abstract 
of  the  methodology  or  technique  in  a  tabular 
format . 
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2.  Main  Processor.  Once  a  particular  package 

has  been  selected,  the  preprocessor  software 
will  provide  the  input  data  set  up  requirements 
for  that  package.  Raw  data  files  will  be 
formatted  to  fit  input  data  requirements  for 
each  package  through  a  software  section 
capable  of  tailoring  the  raw  data  for  that 
particular  statistical/analytical  package. 

The  main  processor  will  also  contair  all  of 
the  statistical/analytical  packages.  As  an 
example : 

]a.  Analysis  of  variance 

b.  Analysis  of  covariance 

c.  Data  Transformations 

d.  Distributions  and  Processes 

(1)  Normal 

(2)  Binomial 

(3)  Gamma 

Chi  Square 

(5)  Weibull 

(6)  Log  Normal 

(7)  Exponential 

(8)  Poisson 

e.  Utility  Routines 

(1)  Matrix  Operations 

(2)  Plotting 

f.  Time  Series  Analysis  (Arima) 

g.  Descriptive  Statistics 

(1)  Central  Tendency  and  Moments 

(2)  Curve  Fitting 

li.  Regression  (univariate  and  multivariate) 

i.  USALOGC  RAM  Rationale  Methodology. 

Finally,  this  processor  will  allow  execution  of 
the  statistical/analytical  package  with  appro¬ 
priately  formatted  raw  data. 
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3. 


Post  Processor.  The  post  processor  software 
will  be  capable  of  providing  appropriate 
outputs  resulting  from  runs  made  of  the 
statistical/analytical  package.  Further, 
this  processor  will  keep  an  audit  of  the 
methods  used  and  resulting  data  in  a  summary 
file  (History  Section  of  the  Management  File) 
by  time,  date,  and  user  such  that  the  statis¬ 
tical  process  could  be  reconstructed  at  a 
later  date. 


Management  Module 


The  function  of  the  Management  Module  is  to 
provide  a  means  for  the  TRADES  Management  Branch 
and  proponents  to  administratively  manage  the 
TRADES  system.  It  achieves  three  basic  purposes: 


(1)  Provide  management  data  for  control  and 
development  of  TRADES . 


(2)  Provide  a  historical  file  of  TRADES 
utilization,  guidelines,  and  changes  in 
TRADES,  and  procedural  notes. 

(3)  Provide  for  scheduling  the  updates  of  the 
other  modules  within  TRADES  on  a  regular 
basis. 


1.  Preprocessor.  This  software  will  provide 

capability  to  retrieve  historical  and  summary 
data  contained  in  a  data  base  of  the  following 
information: 


a.  Additions,  deletions,  changes  -  Interface 
Module  -  software. 


b.  Additions,  deletions  to  Quick  Response 

c.  Additions,  deletions,  changes  to  references 
to  Source  Identification  Module  (to 
include  EEIs). 


d. 


Additions,  changes,  improvements  to 
Statistical/Analytical  Module. 


e.  Inputs  from  proponents.  The  preprocessor 
will  allow  historical  and  summary  review 
of  changes  to  the  Quick  Response  Module 
and  allow  user  "short  notes"  to  be  filed 
under  user  name. 

Main  Processor.  The  software  requirements 
here  will  be  for  a  file  of  changes  to  each  of 
the  five  modules  described  for  the  TRADES 
system  for  the  purpose  of  auditing  usage 
data.  Also,  file  space  will  be  established 
for  "short  notes"  to  be  kept  under  a  particular 
user  name.  The  overall  TRADES  software  will 
be  structured  such  that  the  management 
module  will  be  accessed  for  every  action 
prior  to  entry  into  any  of  the  other  modules. 

Post  Processor.  The  software  required  will 
enable  module  usage  and  data  update  audit 
reports.  Also,  recommendations  for  updates 
to  proponents  will  be  automatically  produced 
for  particular  data  on  a  periodic  basis. 
Software  capable  of  printing  user  "short 
notes"  by  name,  date,  time  and  subject  will 
be  developed  and  implemented  for  analysis  re¬ 
creation  capability.  Finally,  the  post 
processor  executes  proponent  inputs. 


CHAPTER  viii 


GENERAL 


PERSONNEL  REQUIREMENTS 


The  additional  personnel  required  to  operate 
TRADES  are  summarized  in  this  chapter.  These 
personnel  estimates  are  based  on  comparisons  with 
other  systems,  analysis  of  projected  workload,  and 
discussion  with  RAM  engineers  and  data  processing 
support  personnel. 

This  discussion  addresses  the  operation  of  TRADES 
to  include  TRADOC  users,  TRADES  Management  Branch, 
data  processing  element,  and  data  source  personnel. 
The  assessment  on  data  source  personnel  is  not 
complete  since  analysis  was  not  performed  within 
these  activities  in  depth.  However,  assumptions 
on  workload  are  made  which  can  assist  data  source 
management  to  identify  impacts  upon  organization 
computer  and  functional  personnel  resources,  as 
TRADES  reaches  the  implementation  stage. 

USER  REQUIREMENTS 

Major  consideration  is  given  to  the  effect  of 
TRADES  on  the  principal  system  users.  The  big 
question  is,  what  will  be  the  workload  effect  of 
TRADES  on  the  combat  development  activities  in  the 
TRADOC  centers  and  schools.  One  conclusion  reached 
by  the  APJ  team  during  the  investigation  phase  of 
the  concept  study,  was  that  a  large  amount  of  the 
RAM  engineer's  time  (up  to  50%  in  some  cases)  was 
spent  in  locating  sources  and  obtaining  data. 

These  two  functions  are  addressed  directly  by 
TRADES,  with  the  anticipated  effect  of  freeing  up 
at  least  a  portion  of  the  RAM  engineers'  time. 

i 

On  the  other  hand,  the  users  assume  a  monitoring 
and  control  role  for  a  portion  of  the  TRADES 
system. 

The  professional  engineer  will  have  more  data 
available  under  TRADES,  which  may  enable  the 
performance  of  functions  that  were  previously  not 
performed,  based  on  non-available  information.  In 
essence,  the  time  saved  by  TRADES  will  provide  the 
tools  to  enable  the  RAM  engineer  to  do  a  better 
and  more  complete  job. 


Reference  is  made  to  the  workload  calculation 
prepared  in  Chapter  V,  Table  5-4.  The  assumption 
is  made  that  each  end  item,  subsystem,  component, 
and  test  and  support  system  would  generate  from 
one-half  to  one  hour's  activity  by  a  RAM  engineer 
using  the  TRADES  system,  per  year.  Also,  assuming 
that  there  are  251  work  days  available  in  a  typical 
year,  and  68%  of  this  available  time  is  projected 
for  direct  labor;  1365  hours  of  direct  labor  will 
equate  to  one  man  year  of  effort.  The  results  of 
this  calculation  are  portrayed  on  the  chart  in 
Table  8-1,  which  yields  a  high  and  low  range  based 
on  these  estimates.  The  total  requirement  is  for 
7  to  14  personnel,  based  on  either  the  high  or  low 
range  estimate.  Recommended  staffing  level  is  9. 

The  quantity  and  skill  level  recommended  for  the 
combav  development  activities  which  require  them 
are  portrayed  ir.  Table  8-2.  The  education  level 
should  be  a  minimum  of  a  bachelor's  degree  in 
engineering  or  in  the  physical  or  mathematical  sci¬ 
ences.  Experience/training  with  computers  and  com¬ 
puter  systems  is  highly  desirable. 

TRADES  MANAGEMENT  BRANCH 

1.  TRADES  System  Manager  -  The  proper  management 
of  the  TRADES  system  will  require  a  TRADES 
System  Manager  of  appreciable  management 
experience  and  engineering  skills.  Qualifica¬ 
tions  include  a  thorough  understanding  of 
TRADES,  RAM  methodologies,  the  TRADOC  combav 
development  system  and  its  relationship  to 
the  Army,  and  the  availability  of  appropriate 
source  data  flows.  Probable  educational 
background  implies  significant  formal  training 
in  statistics/statistical  methodology,  in 
addition  to  engineering  skills.  Approximately 
six  to  ten  years  of  government  experience, 
system  management  of  at  least  one  automated 
system,  or  significant  experience  in  the 
planning  and  operation  of  such  systems. 

2.  Methodological  and  Analysis  Support  -  Two 
Analysts/  Statisticians  are  required.  These 
personnel  are  primarily  concerned  with  RAM 
methodology  and  techniques.  Required  educa¬ 
tional  background  includes  a  masters  degree 
or  better  in  mathematics/statistics,  and 
preferably  with  a  minor  or  equivalent  in 
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TABLE  8-1.  USER  PERSONNEL  REQUIREMENTS 


USERS 

HIGH 

LOW 

RECOMMENDATIONS 

OCS 

1.6 

.8 

1 

TSCH 

.9 

.45 

l 

MMC3 

1.2 

.6 

1 

QMS 

.2 

.1 

0 

CAC 

.2 

.1 

0 

ANA 

- 

- 

0 

FAS 

1.4 

.7 

1 

INS 

.9 

.45 

1 

ARMC 

.6 

.3 

0 

ADS 

.8 

.4 

1 

SIGS 

1.9 

.95 

1 

ENS 

1.2 

.6 

1 

I  NTS 

.7 

.35 

0 

CHEMS 

.2 

.1 

0 

AVNS 

1.9 

.95 

1 

MPS 

- 

- 

0 

IMA 

— 

- 

0 

LOGC 

- 

- 

0 

AKA 

- 

- 

0 

ASD 

- 

- 

0 

ATSC 

- 

- 

0 

SSC 

- 

- 

0 

0 

TOTALS 

13.7 

6.85 

9 
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TABLE  8-2.  TOTAL  TRADES  TRADOC  PERSONNEL  REQUIREMENTS 


USERS 

DESCRIPTION 

'-'I 

QTY 

OCS 

General  Engineer  (RAM) 

1 

TSCH 

General  Engineer  (RAM) 

1 

MMCS 

General  Engineer  (RAM) 

1 

FAS 

General  Engineer  (RAM) 

1 

INS 

General  Engineer  (RAM) 

1 

SIGS 

General  Engineer  (RAM) 

1 

ENS 

General  Engineer  (RAM) 

1 

AVNS 

General  Engineer  (RAM) 

1 

ADS 

General  Engineer  (RAM) 

1 

TRADES  MANAGEMENT  BRANCH 

LOGC 

Supervisory  General  Engineer  (RAM) 

1 

LOGC 

Analysts/Statisticians 

2 

LOGC 

Computer  Specialist  (Sys  Anl) 

1 

LOGC 

General  Engineer  (RAM) 

1 

LOGC 

Clerk  Typist 

1 

DATA  PROCESSING  ELEMENT 

LOGC 

Senior  Programmer 

1 

SOURCES 

No  quantified  estimates  have  been  made. 

TOTAL  16 

physical  sciences  or  engineering.  Professional 
experience  should  include  three  to  six  years 
of  system  analysis  involving  inferences  from 
data  and  an  ability  to  handle  computers. 

3.  Source  and  User  Services  -  These  positions 
require  one  Ge;  eral  Engineer  (RAM)  and  one 
with  educational  background  of  at  least  a 
bachelor's  degree,  and  three  years  analysis 
experience . 

4.  Clerical  support  is  provided  by  a  single 
clerk,  and  should  ideally  be  a  "career  progres¬ 
sion"  job.  The  work  level  may  ultimately 
justify  two  personnel  in  this  area. 

These  personnel,  as  described  in  Chapter  V,  would 
be  assigned  to  the  RAM/ILS  Division  of  the  Materiel 
Systems  Directorate,  LOGC. 

DATA  PROCESSING  ELEMENT  STAFFING 

This  element  requires  a  senior  programmer  to  serve 
as  the  point  of  contact  in  the  Operations  Analysis 
Directorate  for  TRADES.  Programming  changes  and 
other  special  requirements  would  be  a  part  of  this 
function.  Educational  experience  should  include 
at  least  a  bachelor's  degree  in  computer  science, 
with  additional  training  in  analysis.  Three  to 
five  years  experience  in  computer  programming/ 
systems  analysis  is  considered  essential. 

Other  support  personnel  in  OAD  are  considered  to 
be  sunk  costs,  with  computer  services  provided  by 
the  Computer  Support  Division. 

DATA  SOURCES 

It  is  conceivable  that  the  development  and  implementa 
tion  of  TRADES  will  place  some  additional  workload 
on  data  sources;  particularly  in  the  developmental 
phases  of  TRADES.  While  these  cannot  be  precisely 
estimated  at  this  time,  it  is  probable  that  the 
development  of  the  Interface  Module  will  require 
some  detailed  coordination  of  source  computer 
support  personnel  with  the  TRADES  system  designers 
and  programmers.  Further,  initial  testing  and 
loading  of  data  will  have  some  impact  on  functional 
personnel.  However,  subsequent  experience  in  the 
use  of.  TRADES  should  reduce  the  personnel  impact 
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as  proficiency  is  attained  and  interactive  processes 
used  to  the  maximum  extent  possible. 

An  additional  function  to  be  performed  by  the 
TRADES  office  will  be  the  development  of  new  data 
and  provision  of  customer  service.  Analysts  will 
assist  in  the  validation  of  new  or  updated  RAM 
data  on  a  continuous  and  controlled  basis  before 
entry  into  the  TRADES  and  provide  customers  (with 
or  without  terminals)  with  periodic  reports  of 
changes  or  modifications  to  TRADES  in  terras  of 
data,  hardware,  software,  management,  procedures, 
and  regulations. 

PERSONNEL  SELECTION 

The  skills  and  professional  and  educational  back¬ 
grounds  portrayed  herein  and  in  Chapter  II  of  the 
ACO  are  an  essential  portion  of  TRADES.  Careful 
selection  of  these  personnel  is  imperative  to  the 
efficient  operation  of  the  system. 


CHAPTER  IX 
CONCLUSIONS 


GENERAL 

This  chapter  presents  conclusions  relative  to  the 
system  technical  characteristics  developed  in  this 
part  of  the  study.  Corresponding  recommendations 
are  given  in  Chapter  X. 

RAM  DATA  REQUIREMENT 

The  implications  of  accurate  forecasting  of  RAM 
requirements  is  a  significant  driver  in  the  Army's 
entire  cost  of  doing  business.  (Careful  structur¬ 
ing  of  reliability  requirements  has  major  implica¬ 
tions  for  the  mission  effectiveness  and  life  cycle 
cost  of  materiel.) 

TRADES  DEVELOPMENT 

This  STP  has  outlined  a  system  that  is  technically 
feasible,  economically  viable,  and  clearly  essential 
to  take  full  advantage  of  the  vastly  improved  RAM 
data  sources  currently  under  development  by  the  Army. 
(The  advent  of  SAMS  and  CTDCS,  and  technological 
advances  in  other  areas  supported  by  automated  data 
systems,  provide  expanded  data  to  the  RAM  engineer 
to  monitor  developmental  and  fielded  systems,  make 
valid  comparison  of  reliability  data  on  a  life  cycle 
basis,  and  establish  requirements  based  on  solid 
knowledge  of  current  and  past  experience.) 

TRADES  DEVELOPMENT  PROCESS 

A  series  of  management  actions  (set  forth  in  Chapter 
X)  must  also  be  taken  to  ensure  continuity  of  the 
TRADES  development  process. 


EXTERNAL  TRADES 
SYSTEM  DEVELOPMENT 

The  approved  TRADES  ACO  takes  maximum  advantage  of 
available  LOGO  personnel  and  equipment  by  develop¬ 
ment  under  the  PFDB  umbrella.  It  should  ultimately 
be  a  basic  module  of  the  total  PFDB  capability. 

INTERNAL  TRADES 
SYSTEM  DESIGN 

TRADES  is  designed  to  take  maximum  advantage  of 
state-of-the-art  DBMSs  and  languages.  TRADES  may 
minimize  new  software  development  to  the  extent 
possible  by  using  PFDB  common  software  and  language. 
However,  the  use  of  high  order  languages  should  be 
investigated  to  reduce  post-development  software 
support  and  provide  maximum  ease  of  use  of  the 
capabilities  of  TRADES. 

TRADES  IMPLEMENTATION 
MILESTONES 

With  the  completion  of  concept  development,  there 
will  be  sufficient  information  and  structure  to 
proceed  to  system  definition  and  design,  system  de¬ 
velopment  and  deployment . 

TRADOC  TEST  DATA 

There  is  currently  no  common  automated  system  within 
TRADOC  to  capture  raw  data  from  tests  performed 
within  TRADOC.  There  is  a  requirement  that  these 
test  results  be  an  integral  part  of  TRADES  and 
available  on  an  interactive  basis,  particularly 
during  the  conduct  of  tests  and  to  maintain  an  audit 
trail  of  past  efforts. 
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CHAPTER  X 
RECOMMENDATIONS 


GENERAL 


This  chapter  presents  recommendations  based  on  the 
conclusions  arrived  at  in  Chapter  IX  and  on  the  re¬ 
sults  presented  in  Parts  III  and  IV.  Specific 
recommendations  are  as  follows: 

RAM  DATA  REQUIREMENT 

Continue  the  development  of  TRADES.  There  is  con¬ 
clusive  evidence  that  the  system  is  needed  by  the 
combat  development  community,  with  a  high  proba¬ 
bility. 

TRADES  DEVELOPMENT 

Initiate  appropriate  life  cycle  management  actions 
to  expedite  system  development  in  accordance  with 
AR  18-1  and  TB  18-100.  These  actions  include: 

a.  Appoint  a  Project  Officer  for  TRADES 

b.  Prepare  a  charter  which  contains  the  specific 
authority  and  responsibility  of  the  PM  for  get¬ 
ting  the  system  developed  and  deployed. 

c.  Prepare  a  System  Decision  Paper  (SDP)  to  forma¬ 
lize  completion  of  the  Concept  Development  Phase 
of  the  TRADES  automation  life  cycle. 

d.  Develop  a  Management  Plan  (MP)  within  120  days 
of  appointment  of  the  PM. 

e.  Designate  the  RAM/ILS  Division  of  the  U.S.  Army 
Logistics  Center  as  the  Functional  Proponent  (I'D) 
and  Proponent  Agent  (PA)  for  TRADES  for  functional 
development  of  TRADES. 

f.  Designate  the  Planning  Factors  Management  Division 
of  the  Logistics  Center  r  .ssigned  Responsible 
Agency  (ARA)  for  technica  de\ slopment  of  TRADES. 
This  includes  responsibility  for  production  of 
ADP  software  that  automates  the  fine  ional  system. 
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TRADES  DEVELOPMENT 
PROCESS 


Initiate  management  tasks  necessary  for  the  TRADES 

development  process: 

a.  Organize  a  TRADES  Management  Branch  during 

FY  1983.  This  branch  would  assume  program  man¬ 
agement  functional  responsibilities  for  TRADES. 

b.  Prepare  an  Army  regulation  to  support  data  re¬ 
quirements  and  management  responsibilities  for 
the  formalization  of  TRADES. 

c.  Take  full  advantage  of  sunk  costs  by  LOGO  and 
TRADOC  -*n  the  programming  and  implementation  of 
TRADES . 

d.  Plan  an  implementation  date  of  early  1985  for 
the  developed  TRADES  System. 

e.  Plan  necessary  personnel  augmentation  to  propo- 
nen  ,s. 

EXTERNAL  TRADES 
SYSTEM  DEVELOPMENT 

Continue  necessary  actions  to  bring  TRADES  into 

synchronization  with  PFDB  as  rapidly  as  possible. 

These  actions  include  the  following: 

a.  Initiate  a  functional  description  in  detail 
equivalent  to  the  DFSR. 

b.  Initiate  data  collection  activities  for  hard 
copy  reports,  for  both  source  identification  and 
to  avoid  loss  of  data.  Action  should  be  taken 
to  identify,  inventory,  assess,  and  render 
accessible  hard  copy  information  within  the 
TRADOC  community. 

c.  Initiate  a  prototype/pilot  TRADES  program  to 
capitalize  on  the  hard  copy  development  actions 
indicated  in  b.  above,  in  a  sequence  as  outlined 
on  pages  2-16  and  2-17  of  the  ACO. 


INTERNAL  TRADES 
SYSTEM  DESIGN 


Apply  the  following  concept  and  strategy  la  internal 
TRADES  system  design: 

a.  Use  the  TRADES  logical  and  modular  concept  struc¬ 
ture  developed  by  the  STP. 

b.  Insure  that  TRADES  remains  portable  in  its  de¬ 
sign  and  development  characteristics  to  ensure 
that  it  is  not  bound  to  one  specific  set  of  hard¬ 
ware  . 

TRADES  IMPLEMENTATION 
MILESTONES 

Implement  a  milestone  sequence  for  TRADES,  with  in¬ 
tervals  corresponding  to  the  following  baseline 
schedule : 


Item 

DO /OR 

START 

COMPLETE 

Appoint  PO 

Jan  82 

Prepare  Charter 

Mar  82 

May  82 

Prepare  SDP 

Feb  82 

Mar  82 

Prepare  Management  Pian 

Jan  82 

May  82 

Designate 

Apr  82 

Designate  ARA 

Apr  82 

Initiate  FD 

Dec  81 

Aug  82 

Organize  TRADES 

Management  Branch 

Sep  82 

Initiate  Data  Collection 

Sep  82 

Mar  85 

(Joins  PFDB/TRADES) 

Initiate  Pilot  Program 

Sep  82 

Mar  85 

(Joins  PFDB/TRADES) 

(continued) 


TRADOC  TEST  DATA 

Initiate  effort  within  TRADOC  to  implement  a  standard¬ 
ized  data  collection  system  which  will  provide  compu¬ 
terized  data  from  TRADOC  test  activities  for  use  in 
TRADES. 
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LIST  OF  REFERENCES 


LSAR 


TECOM 


CTDCS 


COMRAM 


The  following  constitutes  a  list  of  key  references 
consulted  during  the  investigation  and  development 
of  the  system  technical  paper  for  TRADES. 

The  references  are  organized  by  major  RAM  data 
sources,  followed  by  general  publications  and 
other  data  sources. 


1.  DARCOM-P  750-16,  "Maintenance  of  Supplies  & 
Equipment  -  DARCOM  Guide  to  Logistic  Support 
Analysis",  June  1980. 

2.  MRSA  Publication,  "A  User’s  Guide  for  Logistic 
Support  Analysis  Record  (LSAR)  Release  Two- 
Automatic  Data  Processing  System",  March  1981. 

3.  MRSA  Publication,  "LSAR  Optional  Systems 
Functional  &  ADP  Guide",  March  1981. 

4.  MRSA  Publication,  "LSAR  ADP  Guide  for  Functional 
Personnel",  September  1980. 


1.  DTIC  Demand  Bibliography,  Search  Control  No. 

004500,  "Army  Test  &  Evaluation  Command  Reports" 


1.  DARCOM  Publication,  "Common  Test  Data  Collection 
Syste n  -  General  Functional  System  Requirement", 
9  November  1979.  1 

2.  DARCOM  Publication,  "Common  Test  Data  Collection 
System  Specification",  July  1980. 


1.  OTEA  Publication,  "Common  RAM  Data  Base  System 
Version  II",  1  February  1981. 

2.  OTEA  Publication,  "Catalog  -  USAOTEA  Test 
Documentation  1973-1979". 


TAERS/TAMMS 


1.  TM  38-750,  "The  Army  Maintenance  Management 
System  (TAMMS)",  May  1981. 


T? 


SDC 


1.  AR  750-37,  "Maintenance  of  Supplies  and  Equipment 

-  Sample  Data  Collection  -  The  Army  Maintenance 
Management  System  (TAMMS)",  2  May  1977. 

2.  DARCOM  Supplement  1  to  AR  750-37,  "Maintenance 

of  Supplies  and  Equipment  -  Sample  Data  Collection 

-  The  Army  Maintenance  Management  System  (TAMMS)", 
17  September  1979 

SAMS 

1.  HQs  DA  Publication,  "Executive  Summary  - 
Standard  Army  Maintenance  System  (SAMS)  - 
Maintenance  Program  Operations  Management  (MPOM)", 
May  1980. 

2.  TM  38-121-2,  "Functional  Requirements  for  Standard 
Army  Maintenance  System  Maintenance  Operations 
Management  (MOM)  (SAMS-1)  Executive  Summary", 

April  1981. 

3.  TM  38-L26-2,  "Executive  Summary  of  Functional  Re¬ 
quirements  -  Standard  Army  Maintenance  System 
(SAMS)  -  Retail  Level  -  Maintenance  Program 
Operations  Management  (MPOM)  (SAM3-2)",  October 
1980. 

4.  USALOGCEN  Publication,  "SAMS-3". 

5.  Record  of  Meeting  -  Standard  Army  Maintenance 
System  (SAMS)  Wholesale  Level  In-Process  Review 
Conference,  St.  Louis,  MO,  10-12  April  1979. 

General  Information 

1.  DoD  Standard  7935. 1-S,  "Department  of  Defense 
Automated  Systems  Documentation  Standards", 

13  September  1977, 

2.  DoD  Inst.  5000.39,  "Acquisition  and  Management 
of  Integrated  Logistics  Support  for  Systems 
and  Equipment",  17  January  1980. 

3.  DoD  Inst.  5000.40,  "Reliability  and  Maintaina¬ 
bility",  8  July  1980. 
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4.  AR  18-1,  "Army  Automation  Management",  15  August 
1980. 

5.  AR  70-10,  "R&D  Test  &  Evaluation  During  Develop¬ 
ment  and  Acquisition  of  Materiels",  29  August  1975. 

6.  AR  335-15,  "Management  Information  Control 
System",  15  March  1978. 

7.  AR  700-127,  "Integrated  Logistics  Support", 

1  April  1981 

8.  AR  702-3,  "Army  Materiel  Reliability,  Availability, 
and  Maintainability  (RAM)",  15  November  1976. 

9.  Draft  AR  702-3,  "Army  Materiel  Systems 
Reliability,  Availability,  and  Maintainability  (RAM), 
23  July  1981. 

10.  FM  101-10-1,  Staff  Officer's  Field  Manual 

Organizational,  Technical  and  Logistic  Data 
(Unclassified  Data)",  July  1976. 
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11.  TB-18-106,  "Deployment,  Operations  and  Termination 
of  Automated  Data  Systems",  September  1980. 

12,  SB  700-20,  "Army  Adopted/Other  Items  Selected 
for  Authorization/List  of  Reportable  Items", 

July  1980. 


13.  TRADOC  Pam.  71-12,  "Combat  Developments  Staff 
Officer's  Handbook",  November  1979. 

14.  TRADOC  Reg.  700-1,  "Integrated  Logistic  Support", 
15  July  1977. 

15.  TRADOC/DARCOM  70-2,  "Material  Acquisition 
Handbook",  January  1980. 

16.  USALOGCEN  Printout,  "TRADOC  Developmental  Hardware 
Projects"  (Para.  3  of  TRADOC  Reg.  700-1  Para.  11), 
2  June  1981. 

17.  BDM  Services  Company,  "Final  Report  -  Design  and 
Development  of  a  Planning  Factors  Data  Base 
(Phase  I)",  Volumes  1  through  IV,  31  May  1979. 
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18.  APJ  892-2,  "TRADOC  RAM  Data  Evaluation  System 
(TRADES)  (ACN  51735)",  System  Requirements 
Description,  July  1981. 

19.  APJ  892-3  "TRADOC  RAM  Data  Evaluation  System 
(TRADES)  (ACN  51235)",  Alternative  Concepts  of 
Operation,  September  1981. 

20.  TB  18-100,  Army  Automation  Life  Cycle  Management, 
August  1981. 
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APPENDIX  B 


AGENCIES /PERSONNEL  CONSULTED 
•  DURING  THE  STP  DEVELOPMENT 


ACTIVITY 

LOCATION 

PERSON  CONTACTED 

Operational  Test 
&  Evaluation  Agency 

Falls  Church,  VA 

R.  Briggs 

USA  Ordnance 

Center  &  School 

Aberdeen  Proving 
Ground,  MD 

T.  Saponaro 

USA  Signal 

Center  &  School 

Ft .  Gordon ,  GA 

R.  Kidd 

Operations  Analysis 
Directorate,  USA 
Logistics  Center 

Ft .  Lee ,  VA 

F.  May 

G.  McBryde 

P.  Jacobsen 

Materiel  Systems 
Directorate,  USA 
Logistics  Center 

Ft.  Lee,  VA 

D.  Lindquist 

Data  Processing 

Field  Office 

Ft .  Leavenworth 
Kansas 

MAJ  Timmons 

BDM  Corporation 

Norfolk,  VA 

R.  Yoshikawa 

APJ 

Ridgefield,  NJ 

G.  Chernowitz 

J.  Ciccotti 

J.  Arnold 
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2  S  OCT  1981 

DTIC-S 


SUBJECT:  Defease  RDT&E  On-Line  System  Asynchronous  Dial-Up 


Mr.  Joe  Arnold 
2A01  Birchett  Drive 
Prince  George,  VA  23875 


Dear  Mr.  Arnold: 

Thank  you  for  your  inquiry  into  the  Defense  RDT&E  On-Line  System  (DROLS).  DROLS, 
an  interactive  retrieval,  input,  and  document  ordering  system,  provides  access  to 
three  data  bases*  The  release  of  data  from  these  data  bases  is  to  be  used  only  in 
support  of  your  Government  contract  work. 

* 

a.  Research  and  Development  Program  Planning  (R&DPP)  Data  Base  -  contains 
1  page  summaries  of  planned  R&D  project  and  task  level  summaries. 

b.  Research  and  Technology  Work  Unit  Information  System  (WUIS)  Data  Base  - 
contains  1  page  summaries  of  on-going  DoD  research  and  technology  efforts  at  the 
work  unit  level. 

c.  Technical  Reports  (TR)  Data  Base  contains  bibliographic  records  of 
technical  reports  submitted  to  DTIG. 

Practically  all  of  DTIC's  collection  can  be  searched  through  DROLS.  The  last  10 
years  of  the  TR  abstracts  can  be  fully  displayed.  For  documents  older  than  10 
years  all  fields  except  subject  retrieval  terras  and  abstracts  are  displayable. 
Citations  to  classified  id  unclassified  reports  and  limited/unlimited  distribution 
reports  are  available. 

Most  of  the  standard  bibliographic  items  such  as  author,  source  (organizations), 
report  date,  title  (through  a  title  key),  and  subjects  are  searchable.  Free-text 
searching  of  the  narrative  fields  is  available  on  a  limited  basis.  For  some  data 
bases,  nonbibliographic  data  is  also  searchable  as  project  numbers,  contact,  and 
funding  sources. 


DT1C-S  PAGE  2 

SUBJECT:  Defense  RDT&E  On-Line  System  Asynchronous  Dial-Up 

DKOLS  will  communicate  with  any  terminal  (CRT  or  typewriter)  which  employs  the 
standard  ASCII  asynchronous  protocol.  Terminal  communications  speeds  will  be  at 
300  or  1200  baud  (30  or  120  characters  per  second)  in  even  parity.  Access  may  be 
gained  by  using  the  TYMNET  commercial  data  communications  network,  FTS,  WATS,  or 
Direct  Dial. 

There  will  be  a  charge  of  $20.00  per  connect  hour  or  proportionate  share. 
Subscribers  to  this  service  must  have  a  deposit  account  with  the  National 
Technical  Information  Service.  This  account  will  be  used  for  billing  purposes 
based  on  connect  time. 

Although  only  unclassified  information  will  be  displayed,  DoD  regulations  require 
that  only  contractor  employees  cleared  to  Confidential  under  the  provisions  of  a 
Governmental  contractor  security  program  may  be  authorized  to  operate  remote 
terminals  or  have  uncontrolled  access  to  systems  terminals.  In  addition,  the 
organization  must  have  a  Confidential  facility  clearance.  Questions  pertaining 
to  personnel  and  facility  clearances  should  be  referred  to  your  security  office. 
Procedures  outlined  in  the  Industrial  Si  arity  Regulation,  DoD  5220. 22-R,  apply. 
Appendix  B  of  the  regulation  which  provides  information  regarding  cognizant 
security  offices  is  provided  for  your  information  (Enclosure  1). 

Enclosure  2  is  a  DTIC  policy/information  sheet  on  the  dial-up  capability  of  the 
DROLS.  If  you  wish  to  gain  access,  complete  Enclosure  3  and  forward  a  written 
request  to  DTIC.  Written  certification  of  clearance  must  be  provided  by  your 
security  office  for  each  terminal  operator  before  the  terminal  will  be 
activated. 

When  your  request  is  received,  DTIC  will  contact  you  regarding  a  training 
session,  provide  a  dial-up  telephone  number,  site  identification  and  "Password." 
Once  provided,  control  of  this  information  is  the  responsibility  of  the  user. 

Any  questions  should  be  directed  to  the  On-Line  Support  Office  at  Area  Code 
202-274-7709  or  AUT0V0N  234-7709. 


Sincerely, 

.jki y;)> 

3  Enel  .''JERRY*  i .  MILSTEAD 

On-Line  Support 
Management  Support  Office 
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OPERATIONAL  AREAS  OF  DIS 

COGNIZANT  SECURITY 

OFFICES 

ATLANTA 

Greene 

Saratoga 

Hamilton 

Schenectady 

States  of:  North  Carolina,  South  Carolina,  Georgia, 

Herkimer 

Schoharie 

Tennessee, 

Mississippi,  Alabama,  Florida,  Kunkin  and 

Jefferson 

Schuyler 

Pemiscot  counties  in  Missouri,  —  also  includes  Puerto 

I.ewis 

Scnccu 

Rico  and  U.S.  possessions  in  the  Atlantic  and  Car- 
ihhbcan  areas,  and  the  following  counties  in  Arkan- 

Livingston 

Madison 

Monroe 

Steuben 

Sullivan 

Tioga 

sas: 

Montgomery 

Tompkins 

Arkansas 

Jackson 

Niagara 

Ulster 

Baxter 

Jefferson 

Oneida 

Warren 

Boone 

Lawrence 

Onondaga 

Washington 

Bradley 

ljee 

Ontario 

Wayne 

Calhoun 

Lincoln 

Orleans 

Wyoming 

Clay 

I/>noke 

Oswego 

Yates 

Cleburne 

Marion 

Otsego 

Cleveland 

Mississippi 

Rensslaer 

Craighead  Newton 

Crittenden  Perry 

Cross  Phillips 

Dallas  Poinsett 

Desks  Prairie 

Drew  Pulaski 

Faulkner  Randolf 

Fulton  Saint  Francis 

Garland  Saline 

Grant  Searcy 

Greene  Sharp 

Hot  Springs  Stone 

Independence  Van  Kuren 

hard  White 

Woodruff 

The  following  counties  in  I^ouisiana: 


WASHINGTON 

The  counties  of  Harford,  Baltimore,  Howard,  Anne 
Arundel,  Montgomery,  Prince  Georges,  Calvert,  Saint 
Marys  and  Charles  in  Maryland,  and  the  counties  of 
Loudoun,  Fairfax,  Prince  William,  Arlington,  in 
Virginia,  and  Washington,  D.C.,  and  the  city  of 
Alexandria,  Va. 

CLEVELAND 

States  of  Ohio,  Kentucky,  Indiana,  Michigan,  and 
the  counties  of  Marshall,  Ohio,  Brooke  and  Hancock 
in  West  Virginia,  and  the  counties  of  Jackson, 
Clinton,  Scott,  and  Muscatine  in  Iowa,  and  the 


Assumption 

Saint  Helena 

Adams 

Marathon 

Fast  Baton  Rouge 

Saint  James 

Ashland 

Marinette 

Fast  Feliciana 

Saint  John  the  Baptist 

Brown 

Marquette 

IlH’ria 

Saint  Martin 

Calumet 

Menominee 

Hx'rvillc 

Saint  Mary  (and  part 

Clark 

Monroe 

Jefferson 

of  Saint  Martin) 

Columbia 

Oconto 

Lafayette 

Saint  Tammany 

Crawford 

Oneida 

LaFourche 

Tangipahoa 

Dane 

Outgamic 

Livingston 

Terrebonne 

Dodge 

Ozaukee 

Orleans 

Vermilion 

Door 

Portage 

Pla<|uemines 

Washington 

Florence 

Price 

Poinle  Coupee 

West  Baton  Rouge 

Forest 

Racine 

Saint  Bernard 

West  Feliciana 

FondduLac 

Richland 

BOSTON 

Grant 

Rock 

States  of  Maine,  New  Hampshire,  Vermont,  Massa¬ 
chusetts,  Rhode  Island,  Connecticut,  and  the  follow¬ 

Green 

Green  Ioke 

Iron 

Sauk 

Shawano 

Shelwygan 

ing  counties  in  New  York: 

Iowa 

Taylor 

Albany 

Columbia 

Juneau 

Vernon 

Allegany 

Cortland 

Kewaunee 

Vilas 

Broome 

Delaware 

Kenosha 

Walworth 

Cattaraugus 

Dutchess 

lot 'rosso 

Washington 

Cayuga 

Brie 

I-afayotte 

Waukesha 

•Chautaugua 

Ksscx 

Iongladc 

Waupaca 

Chemung 

Franklin 

Lincoln 

Waushara 

Chenango 

Fulton 

Manitowoc 

Winnclmgo 

Clinton 

Genesee 

Milwaukee 

Wood 
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The  following  counties  in  Illinois: 


Adams 

Effingham 

Roene 

Ford 

Brown 

Fulton 

Bureau 

Grundy 

Cur  roll 

Hancock 

Cass 

Henderson 

Champaign 

Henry 

Christian 

Iroquois 

Clark 

Jasper 

Coles 

Jo  Daviess 

Cook 

Kane 

Crawford 

Kankakee 

Cumberland 

Kendall 

DcKalb 

Knox 

Do  Witt 

Lake 

Douglas 

La  Salle 

DuPage 

Lee 

Edga. 

Livingston 

logan 

Putnam 

Macon 

Rock  Island 

Marshall 

Sangamon 

Mason 

Schuyler 

McDonough 

Scott 

McHenry 

Shelby 

McLean 

SUrk 

Menard 

Stephenson 

Mercer 

Tazewell 

Morgan 

Vermillion 

Moultrie 

Warren 

Ogle 

Whiteside 

Peoria 

Will 

Piatt 

Winnebago 

Pike 

Woodford 

DALLAS 

States  of:  New  Mexico,  Texas,  Oklahoma,  Arizona, 
and  the  following  counties  in  Arkansas: 

Denton  Miller 

Caroll  Montgomery 

Clark  Nevada 

Columbia  Ouachita 

Crawford  Pike 

Franklin  Polk 

Hempstead  Pope 

Howard  Scott 

Johnson  Sebastian 

Lnyfayette  Sevier 

Little  River  Union 

Logan  Washington 

Madison  Yell 

The  following  counties  in  Louisiana: 

Acadia  De  Soto 

Allen  East  Carroll 

Avoyelles  Evangeline 

Beauregard  Franklin 

Bienville  Grant 

Bossier  Jarkson 

Caddo  Jefferson  Davia 

Calcasieu  l«a  Salle 

Caldwell  Lincoln 

Cameron  Madison 

Catahoula  Morehouse 

Claiborne  Natchitoches 

CVincordia  Ouachita 


I)oI)  5220.22-K 


Rapides 
Rrsl  River 
Richland 
Sabine 

Saint  Landry 
Tensas 


Union 
Vernon 
Webster 
Wes-,  Carroll 
Winn 


LOS  ANGELES 

Includes  state  of  Hawaii  &  U.S,  possessions  &  trust 
territories  in  the  Pacific  area,  and  the  following 
counties  in  California: 

Irnjrerial  San  Rernadino 

Inyo  San  Diego 

Kern  San  Luis  Obispo 

Los  Angeles  Santa  Barbara 

Orange  Ventura 

Riverside 

The  following  counties  in  Nevada: 

Clark  Lincoln 

Esmeralda  Nyc 

NEW  YORK 

The  following  counties  in  New  York: 

Bronx  Putnam 

Kings  Queens 

(Rrooklyn)  Richmond 

Nassau  Rockland 

New  York  Suffolk 

(Manhattan)  Westchester 

Orange 

The  following  counties  in  New  Jersey: 

Bergen  Morris 

Essex  Passaic 

Hudson  Somerset 

Hunterdon  Sussex 

Middlesex  Union 

Monmouth  Warren 

PHI  IjA  DELPHI  A 

States  of:  Pennsylvania,  Delaware,  West  Virginia 
(less  the  counties  of  Marshall,  Hancock,  Brooke  and 
Ohio),  Virginia  (loss  the  counties  of  Ixmdoun,  Fair¬ 
fax,  Prince  William  and  Arlington),  Maryland  (less 
the  counties  of  Harford,  Baltimore,  Howard,  Anne 
Arundel,  Montgomery,  Prince  Georges,  Calvert,  Saint 
Marys  and  Charles),  Chautauqua  county  in  New 
York,  and  the  following  counties  in  New  Jersey: 
Atlitntic  Camden 

Burlington  Cnpe  May 

Cumlwrlnml  Ocean 

Gloucester  Salem 

Mercer 

SAINT  LOUIS 

States  of:  N.  Dakota,  S.  Dakota,  Minnesota,  Ne¬ 
braska,  Colorado,  Kansas,  Missouri  (less  Dunkin  and 
Pemiscot  counties),  Iowa  (less  Jackson,  Clinton,  Scott 
and  Muscatine  counties),  and  the  following  counties 
in  Wisconsin: 

Romm  Burnett 

Bayfield  Chip|>«‘wa 

Buffalo  Douglas 
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Dunn 

Fau  Claire 
Jackson 
IV|>in 
Tierce 


Polk 

Rush 

Saint  Croix 
Sawyer 
Trempealnau 
Waahbur- 


* » uiiuuni 

The  following  counties  in  Montana: 

Carter  Prairie 

Daniel*  Roosevelt 

Dawson  Richland 

McCone  Sheridan 

Powder  River  Wibaux 

The  following  counties  in  Wyoming: 

Albany  Fremont 

Cambell  Goshen 

Carbon  Laramie 

Converae  Natrona 

Crook  Niobrara 

Platte  Weston 


The  following  counties  in  Illinois: 

Alexander  Jacks 

Bond  Jefferson 

Calhoun  Jersey 

Clay  Johnson 

Clinton  Lawrence 

Ed  wards  Macoupin 

Fayette  Madison 

Franklin  Marlon 

Gallatin  Massac 

Green  Monroe 

Hamilton  Montgomery 

Hardin  Perry 

Pope  Union 

Pulaski  Wabash 

Randolph  Washington 

Richland  Wayne 

St.  Clair  White 

Saline  Williamson 

SAN  FRANCISCO 

States  of:  Washington,  Oregon,  Idaho,  Utah,  Alas¬ 
ka,  and  the  following  counties  in  Wyoming: 

Hi*  Horn  Sublette 

Hot  Springs  Sweetwater 

Johnson  Teton 

Lincoln  Uinta 

Park  Washakie 

Sheridan 

The  following  counties  in  Montana: 

Rraverhead  Broadwater 

Rig  Horn  Carbon 

Blaine  Cascade 


Chauleau 

Cuoter 

Deer  lxxlge 

Fallon 

Fergus 

Flathead 

Gallatin 

Garfield 

Glacier 

Golden  Valley 

Granite 

Hill 

Jefferson 
Judith  Basin 
Lake 

Lewis  and  Clark 

Lil>erty 

Lincoln 

Madison 

Meagher 


Mineral 

Missoula 

Musselshell 

Park 

Petroleum 

Phillips 

Pondera 

Powell 

Ravalli 

Rosebud 

Sanders 

Silver  Bow 

Stillwater 

Sweet  Grass 

Teton 

Toole 

Treasure 

Valley 

Wheatland 

Yellowstone 


The  following  counties  in  Nevada: 


Churchill 

Douglas 

Elko 

Eureka 

Humboldt 

Lander 


Lyon 

Mineral 

Pershing 

Storey 

Washoe 

White  Ihne 


The  following  counties  in  California: 


Alameda 

Alpinj 

Amador 

Butte 

Calaveras 

Colusa 

Contra  Costa 

Del  Norte 

0  Dorado 

Fresno 

Glenn 

Humboldt 

Kings 

Lake 

Lassen 

Madera 

Marin 

Mariposa 

Mendocino 

Merced 

Modoc 

Mono 

Monterey 

Napa 


Nevada 

Placer 

Plumas 

Sacramento 

San  Benito 

San  Francisco 

San  Joaquin 

San  Mateo 

Santa  Clara 

Santa  Crux 

Shasta 

Sierra 

Siskiyou 

Solano 

Sonoma 

Stanislaus 

Sutter 

Tehama 

Trinity 

Tulare 

Tuolumne 

Yolo 

Yuba 


TELEPHONE  NUMBERS  AND  ADDRESSES 

The  following  listing  contains  the  addresses  and  telephone  numUtrs  of  all  Cognizant  Security  Offices.  (The 
following  indicated  telephone  numlwrs  and  addresses  shall  be  used  to  obtain  the  required  verification  of  facility 
clearance  and  safeguarding  capability  of  prospective  contractors  and  subcontractors.) 
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Area 

Telephone 

Citj_4-SUk 

Address 

Cade 

Numbur 

Atlanta,  GA 

805  Walker  St. 

404 

429-6340 

Marietta,  GA  30060 

Boston,  MA  02210 

666  Summer  Street 

617 

542-6000,  ext  838 

Cleveland,  OH  44199 

Federal  Office  Bldg. 

216 

622-5338/9 

1240  East  9th  Street 

Dallas,  TX  75201 

Merchandise  Mart  Bldg. 

214 

670-9276 

500  South  Ervay  Street 

1/Os  Angeles,  CA  90045 

11099  S.  LaCienega  Blvd. 

213 

643-0200 

New  York,  NY  10013 

60  Hudson  Street 

21 2 

374-9040 

Philadelphia,  PA  ldlOl 

P.0.  Box  7478 

215 

952-4030 

2800  South  20th  Street 

San  Francisco,  CA  94129 

Preside,  of  San 

Francisco 

415 

561-6235 

St.  Louis,  MO  <3101 

1136  Washington  Street 

314 

263-6581 

Washington,  D.C. 

2461  Eisenhower  Ave, 

202 

325-9616 

(Capital  Region) 

Alexandria,  VA  22331 

Area 

Telephone 

AUTOVON  NO. 

CognizanL  Security  Office 

Cods 

Number 

fFor  Govt.  Agencies  Use) 

Atlanta 

404 

429-6340 

697-6340 

Boston 

617 

542-6000,  ext  805 

955-8805 

Cleveland 

216 

522-5334 

580-5334 

Dallas 

214 

670-9270 

940-1270 

l/'s  Angeles 

213 

643-1082 

833-1082 

New  York 

212 

374-9040 

904-9046 

Philadelphia 

215 

952-4030 

444-4030 

San  Francisco 

4>5 

561-3572 

586-6235 

St.  Louis 

314 

263-5580 

693-6580 

Washington  (Capital  Region) 

202 

325-9161 

221-9616 

The  following  listing  contains  the  addresses  and  telephone  numbers  of  DISCO,  DISI  and  OISI. 


City.  &-StAte 

DISCO,  Columbus,  OH  43216 


DISI.  Richmond,  VA  23297 


Area 

Telephone 

Addrsu 

Cede 

Number 

P.O.  Box  2499 

614 

236-2133  (Duty  Hrs) 

614 

236-2058  (After  Hrs) 

AUTOVON  NUMBER  (For  Govt.  Agencies  Use)  850-2133  (Duty  Hrs) 

c/o  Defense  General  Supply  Center  804  275-4891 

AUTOVON  NUMBER  (For  Govt.  Agencies  Use)  6954891 


OISI,  Brussels,  Belgium  JEjhyflkftl _Addn.1i; Office  of  Industrie)  Brussels,  Belgium 

Security,  International  720-8259 

Chaussee  de  I-ouvain,  13 
1940  St  Stevens,  Wotuwe,  Belgium 

Mailing  Address;  Office  of  Industrial 
Security.  International 
A  1*0  New  York  09667 
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ASYNCHRONOUS  DIAL-UP  POLICY/ I NFORMATI ON 


I .  User  Charges 


a.  All  dial-up  users  will  pay  $20  per  connect  hour. 

b.  All  dial-up  users  roust  have  a  NTIS  Deposit  Account. 

c.  No  charge  for  batch  printing. 

d.  No  charge  for  time  spent  on  input. 

e.  No  charge  to  users  for  use  of  TYMNET  Communications  Network. 

f.  No  charge  for  training. 

I I .  Training 

a.  Those  using  asynchronous  terminals  for  access  will  be  trained 
at  DTIC . 

b.  Training  will  be  for  3  days. 

c.  Requests  for  training  at  remote  sites  will  be  considered  on  a 
case-by-case  basis.  The  decision  will  be  based  on  the  number 
of  users  to  be  trained,  availability  of  a  training  site  and 
terminals,  and  the  availability  of  DTIC  training  personnel. 

d.  Training  classes  will  be  limited  to  a  maximum  of  10  people. 
(One  person  per  site  unless  room  is  available). 

e.  No  users  will  be  added  without  at  least  one  operator  being 
trained  at  DTIC.  If  a  dial-up,  asynchronous  user  has  had 
experience  with  a  commercial  system  such  as  Dialog  or  Orbit, 
they  may  be  added  without  attending  a  DTIC  training  session 
with  the  approval  of  the  DTIC  On-Line  Support  Office 
(DTIC-SM). 

f.  Usage  of  the  system  by  dial-up  users  will  be  closely  monitored 
to  assure  equitable  distribution  of  dial-up  facilities, 

g.  One  copy  of  the  reference  tools  will  be  provided  to  euch  site 
free  of  charge;  any  additional  copies  would  have  to  be 
purchased . 


Enel  2 
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III.  bach  site  will  he  given  a  unique  "I’asswo,  I”  wlileh  will  1m-.1  (’hanged 
quarterly  or  as  requited.  Initially,  multiple  terminals  at  the  same 
site  will  be  given  the  same  password. 

IV.  Credit  for  down  time  will  he  given  when  a  user  feels  that  credit 
Is  due  and  applies  to  the  DT1C  On-Line  Support  Office  (DTIC-SM)  lr.  each 
instance. 

V.  The  size  of  bibliographies  batched  will  be  limited  to  200 
citations.  If  a  larger  output  is  needed,  users  will  contact  the 
On-Line  Support  Office  (DTIC-SM),  Area  Code  202  274-7709  or  AIIT0V0N 
284-7709,  who  will  arrange  to  have  the  searches  run  by  DTIC  personnel. 

VI.  All  contractor  employees  operating  or  having  uncontrolled  access 
to  terminals  must  be  cleared  through  Confidential  under  a  Government 
contractor  security  program. 

VII.  All  contractor  facilities  must  have  a  Confidential  facility 
clearance. 
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Opcratlon.il  Mours_  _ _ 

DTJC  User  Code _ 

NT1S  Deposit  Account  Number _ 

Which  communications  method  do  you  plan  to  use  to  access 
DROLS  via; 

a.  TYMNET 

b.  FTS 

c .  WATS 

d.  Direct  Dial 

Terminal  Type /Model _  _ 

CRT  or  Teleprinter _ _ _ 

Printer  Type/Model  (Optional) _ 

Asynchronous  transmission  speed  you  wish  to  operate  at: 

a.  300 

b.  _ _1200 

Modem  Type/Model _ _ _ _ _ _ _ 
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GLOSSARY 


ACO 

ADP 

ADPE 

ADS 

ALDT 

ARA 

COEA 

COMRAM 

CPU 

CRT 

CTDCS 

CTP 

DBMS 

DFSR 

DLSIE 

DPFO 

DROLS 

DT 

DTIC 

EEA 

EEI 

FD 
FP 
FSR 
FT  3 

LOA 

LSAR 

MMLA 

MP 

MR 

MUSA 

MTBF 

MTBOMF 

MTBUMA 

MTTR 

NBC 


Alternative  Concept  of  Operation 
Automatic  Data  Processing 
Automatic  Data  Processing  Equipment 
Automated  Data  Systems 
Administrative  and  Logistic  Downtime 
Operational  Availability 
Assigned  Responsible  Agency 

Cost  and  Operational  Effectiveness  Analysis 
Common  RAM  System 
Control  Processing  Unit 
Cathode  Ray  Tube 

Common  Test  Data  Collection  System 
Coordinated  Test  Program 

Data  Base  Management  System 

Detailed  Functional  System  Requirements 

Defense  Logistics  Services  Information  Exchange 

Data  Processing  Field  Office 

Defense  RDT&E  On-Line  System 

Development  Test 

Defense  Technical  Information  Center  . 

Essential  Elements  of  Analysis 
Essential  Elements  of  Information 

Functional  Description 
Functional  Proponent 
Final  Study  Report 
Federal  Telephone  Service 

Letters  of  Agreement 

Logistics  Support  Analysis  Report 

Maintenance  Manpower  &  Logistics  Analysis 
Management  Plan 
Maintenance  Ratio 

Materiel  Readiness  Support  Activity 
Mean  Time  between  Failure 

Mean  Time  between  Operational  Mission  Failure 

Mean  Time  between  Unscheduled  Maintenance  Actions 

Mean  Time  to  Repair 

Nuclear,  Biological,  Chemical 
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GLOSSARY  (Concluded) 


OAD 

OT 

OTEA 

PA 

PFDB 

PFMD 

RAM 

ROC 

SAG 

SAMS 

SDC 

SDP 

SOW 

SRD 

STP 

SWP 

TDLR 

TMIS 

TRADES 

TSM 


Operational  Analysis  Directorate 
Operational  Test 

Operational  Test  &  Evaluation  Agency 

Proponent  Agent 

Planning  Factors  Data  Base 

Planning  Factors  Management  Division 

Reliability,  Availability,  Maintainability 
Required  Operational  Capability 

Study  Advisory  Group 

Standard  Army  Maintenance  System 

Sample  Data  Collection 

System  Decision  Paper 

Statement  of  Work 

System  Requirements  Description 

System  Technical  Paper 

Study  Work  Plan 

Training  Device  Letter  Requirements 
Test  Management  Information  System 
TRADOC  RAM  Data  Evaluation  System 
TRADOC  System  Manager 
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